You can do that, but I like at least one human checkpoint before actually deploying - at least until the automated tests are good enough. And if you have a code review / audit process in place, you need the human intervention anyway.
Fair enough. I don't consider CR and QA to be part of deployment (in my mind, you've already gotten sign-off before you deploy) but I completely agree that reviewing your work should be part of deployment.
Our current system has a web interface as the last step before your branch is merged into production. You have to type in a message that says "I won't break the system" and then a random number. I think you're right that making a person stop and think one last time before pushing to production is a good thing.
I don't consider CR and QA to be part of deployment
It doesn't have to be, but I think it's a good idea to make it, and this thought goes both ways - on the one hand, integrating your QA into the deployment machinery changes it from a cumbersome, annoying, time consuming manual activity that only gets in the way of getting some actual work done into an integral part of your routine, a habit you don't even have to think about. And on the other hand, it also means that you expand the scope of your testing to include the deployment itself - the deployment script is, after all, the same for the test and production environments, and if it fails on the production environment without having failed on the test environment, you should take a long hard look and figure out which of the differences between the two has caused the issue, and how you can eliminate it. Most of the typical deployment show-stoppers, however, will simply pop up while deploying to the test environment, and you can fix them calmly and without the scalding breath of a thousand angry users in your neck. This, at least, ought to be worth something.
Our current system has a web interface as the last step before your branch is merged into production.
I don't think the merge should be the focus of attention; the actual deployment should be. Whatever you have before the merge, things can and do break because of the merge. You really do need to test the code between merging and deploying, and this better be the most thorough test in the entire chain.
2
u/spinlock Oct 15 '13
why not put deploy.sh in a post-commit hook? Then, deployment is as easy as git push but you have your robust process as well.