4 ms·

For a deployment pipeline that takes the HEAD state on the git repo, you are right, that's perfectly fine. However if you have other developers or SRE that have

For a deployment pipeline that takes the HEAD state on the git repo, you are right, that's perfectly fine. However if you have other developers or SRE that have that repo checked out, they'll have problems. Not problems that they can't take care of, but an additional step nonetheless.

chrischen 8y ago
Let me clarify the scenario I'm using, as far as I can see there should not be anyone else touching the repo except production services that depend on it. 1. Push to somewhere (maybe a bare repo, or github/bitbucket). 2. Production clone pulls from the master. If any issues arise, you can do git reset --hard HEAD^ on the production repo to rollback any changes to an arbitrary prior version. > However if you have other developers or SRE that have that repo checked out, they'll have problems What do you mean by this? The production repo should only be read from by production services serving from it (webserver, database, etc). Any engineers shouldn't be making commits to it and merging upstream. It should be purely be used for deployment. I think maybe you're assuming the production repo is also the master repo? This is not something I recommend and if you use my deploy scenario, this is not how it would be setup. The production repo should just be a clone of the master, purely pulling updates from master just like everyone else, which can be on github or another bare repo that others work from. Except the production repo would also be a read-only repo. You obviously don't SSH in, make hot patches, and commit from there. Based on this, what I suggested (git reset --hard HEAD^) and having a repo deployed on the production server is a best practice for deployment. It allows for effortless roll back to arbitrary prior states, easy post-update hooks for build steps. And should upstream ever be updated, it's one command that just re-syncs (git pull) to any of the latest fixes for whatever went wrong.

chrischen 8y ago

Let me clarify the scenario I'm using, as far as I can see there should not be anyone else touching the repo except production services that depend on it. 1. Push to somewhere (maybe a bare repo, or github/bitbucket). 2. Production clone pulls from the master. If any issues arise, you can do git reset --hard HEAD^ on the production repo to rollback any changes to an arbitrary prior version. > However if you have other developers or SRE that have that repo checked out, they'll have problems What do you mean by this? The production repo should only be read from by production services serving from it (webserver, database, etc). Any engineers shouldn't be making commits to it and merging upstream. It should be purely be used for deployment. I think maybe you're assuming the production repo is also the master repo? This is not something I recommend and if you use my deploy scenario, this is not how it would be setup. The production repo should just be a clone of the master, purely pulling updates from master just like everyone else, which can be on github or another bare repo that others work from. Except the production repo would also be a read-only repo. You obviously don't SSH in, make hot patches, and commit from there. Based on this, what I suggested (git reset --hard HEAD^) and having a repo deployed on the production server is a best practice for deployment. It allows for effortless roll back to arbitrary prior states, easy post-update hooks for build steps. And should upstream ever be updated, it's one command that just re-syncs (git pull) to any of the latest fixes for whatever went wrong.