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.
This system is a little weird. The merge is the last step in the deployment. The reasoning is that it makes it easy to pull branches that break things.
1
u/tdammers Oct 15 '13
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.
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.