My current project is taking forever to get off the ground, and that’s fine, because I’m automating everything I can. That means at any time I must be able to wipe out the old site, provision a server, and deploy the new site within minutes, with me having to do little more than run a file and fill in a few passwords.

Obviously there are a lot of good reasons to automate, but the primary reasons are security and, well, I’ll call it idempotency. Idempotent is math term I’m using here to mean that, given the same inputs, you should always get the same output.

Why security is the most important reason your deployment should be automated

I am creating the new site as a one-man band so  I can understand all the issues involved in security, performance, backup, and deployment along with the programming part that I’m so much more comfortable with. I find them much harder. With programming, you can determine easily whether you’ve handled the vast majority of test cases, what queries are fastest, or where indexes should be created.

With deployment and security, you are dealing with constantly moving security targets, a fragmented tools market, and even disagreement on best practices. All of these means that it’s quite possible that no matter how hard you try to avoid it, your site can get cracked. The only practical cure will sometimes be to redeploy to the last known good version, possibly (though, one would hope, rarely) more than once a day. If you don’t automate this whole practice, you run the risk of leaving a security hole open when you redeploy. If you do automate it, you can accrete better and better protection by baking what you’ve learned directly  into your scripts.

Your first job is to be boring

Your audience may not know how to say this, but your first job is to be boring. Each time they visit the site, the good things that worked well last time should still work well this time. If a new feature fails badly enough, you should be able to deploy a previous version of their site with all the old data, but the feature eliminated.

So to misuse the term Idempotency slightly, it’s your job to be able to roll back one of your site’s features while keeping the data current. Given the same data (in this example, version of Apache, version of Python, what patch files you need, which version of your source code repo is necessary, etc.) the result should be the same website they had before you screwed it up.