Simon Willison’s Weblog

What are good and easy practices for frequent web deployments?

My answer to What are good and easy practices for frequent web deployments? on Quora

At Lanyrd we use a combination of Fabric to drive our deploy scripts, git to get the code on to the servers, puppet for configuration management and Jenkins to run continuous integration tests and provide a “deploy the site” button.

Here are a few important techniques I’ve learned:

• Use symlink switching to keep the previous version of the code around, so you can switch back in the case of problems (that said, we’ve never actually used this capability—but its nice for atomic deploys as well)
• Have your build script rename your static asset files (CSS/JS/etc) to include part of the md5 hash of the file contents in their filename. This means you can upload them to your static host provider (we use S3) before you run a deploy, guaranteeing that freshly deployed templates will point to the right files. It also keeps the older versions around in case you need to roll back.
• Having one button that deploys the site is invaluable
• Deploys need to be almost “free” in terms of impact on site performance—if it doesn’t cost anything to deploy the site people will be freely able to deploy often and push out small fixes, which is good for the health of your codebase
• Get new engineers to deploy on the first day! Doing so forces you/them to get a full development and deployment environment up and running for them on day one, which means that they can start doing real work on day two.