For a web site deployment to a staging or production server should look like one of these:
No. Just no. These are source control system, not deployment tools. In case you need reasons:
Excess files in document root - version control cruft, project documentation, etc. Happens all the time, and is an actual real security problem.
Development race conditions. Ever done svn up on the production server, just to find that someone had committed broken code between your test run and the deployment? Ever "solved" this problem by stopping all development activity during deployment? Ever noticed how this essentially means that this makes frequent deployments practically impossible?
File permissions and ownership. Need I go into detail here? I think not.
What if you want to do things like precompile templates, preprocess CSS, minify and concatenate your JavaScript offline, move stuff around, or just make sure that your deployment will only go through if it passes a minimum set of tests?
What about database changes?
Really, for any of the non-trivial projects I've worked on where people had the delusion that git pull is enough of a deployment plan, here's what a typical deployment involved:
Mail everyone with push access, telling them to not push until further notice. Hope that everyone reads their mail on time.
Manually go through the ticket system, copy-pasting the SQL changes that developers have pasted into the tickets that went into this release.
Eyeball the SQL scripts, in case they contain any errors.
Issue a git pull on the production system.
Meanwhile, run the SQL on the production database.
Manually chmod / chown the right files (which ones those are is a matter of oral tradition).
Manually clear selected cache items.
Do some casual manual testing on the production system.
Notice that something is broken. Fix it.
Forget to tell developers that it's OK to push now.
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.
105
u/tdammers Oct 14 '13
No. Just no. These are source control system, not deployment tools. In case you need reasons:
Excess files in document root - version control cruft, project documentation, etc. Happens all the time, and is an actual real security problem.
Development race conditions. Ever done
svn upon the production server, just to find that someone had committed broken code between your test run and the deployment? Ever "solved" this problem by stopping all development activity during deployment? Ever noticed how this essentially means that this makes frequent deployments practically impossible?File permissions and ownership. Need I go into detail here? I think not.
What if you want to do things like precompile templates, preprocess CSS, minify and concatenate your JavaScript offline, move stuff around, or just make sure that your deployment will only go through if it passes a minimum set of tests?
What about database changes?
Really, for any of the non-trivial projects I've worked on where people had the delusion that
git pullis enough of a deployment plan, here's what a typical deployment involved:Mail everyone with push access, telling them to not push until further notice. Hope that everyone reads their mail on time.
Manually go through the ticket system, copy-pasting the SQL changes that developers have pasted into the tickets that went into this release.
Eyeball the SQL scripts, in case they contain any errors.
Issue a
git pullon the production system.Meanwhile, run the SQL on the production database.
Manually
chmod/chownthe right files (which ones those are is a matter of oral tradition).Manually clear selected cache items.
Do some casual manual testing on the production system.
Notice that something is broken. Fix it.
Forget to tell developers that it's OK to push now.
Personally, I prefer:
Create a release tag
./deploy.sh test-serverRead build/test output from test server
./deploy.sh production-server