Strong opinions, weakly held

Preparing for continuous deployment

Since I watched the Tim Fitz video that I linked earlier, I’ve been thinking about continuous deployment. Whether you are really going to deploy every day or not, the idea that your code base is always in a position where it could be deployed immediately is enticing. As Tim points out, getting your code into that shape means that you’re getting a lot of things correct.

So I thought I’d break it down a bit and look at the steps required to get an application in shape for continuous deployment. From the presentation, it seems like the major steps are as follows:

  • Get your house in order with regard to deployment. If you’re going to be deploying frequently, you need a fully automated deployment system that works quickly and effectively across your whole cluster. The complexity goes up if you’re pushing database schema changes that would ordinarily require downtime. You also need the ability to easy roll back your deployments in case things go wrong.
  • Set up a robust suite of automated tests. To set up continuous deployment with confidence, you need to feel pretty comfortable that bugs won’t make it past your test suite. If you don’t have tests, this is a big hurdle to overcome.
  • Set up a continuous integration system. Once your tests are set up, you need to automate them so that they’re run every time code is committed. If necessary, you have to set up this system in parallel so that tests run quickly enough not to gum things up. (In the presentation, Fitz mentions that their full test suite takes 6 CPU hours to run and is split among 40 machines).

  • Build a monitoring system that is effective in catching post-deployment problems. When you’re deploying all the time and relying almost solely on automated testing to verify your builds, you want to monitor your application to make absolutely sure that everything is in order while it runs. This is your last and best line of defense against errors that are causing problems in production but that you haven’t noticed yourself.

While all of those things are necessary to implement a continuous deployment system effectively, it seems like these are all features you’d want for any application. I’m going to explore getting the application I work on into a state where it could move to a continuous deployment and write up what it takes to get all of the prerequisites set up.

The big question is whether it’s possible to invest the effort to put the work into setting things up so that continuous deployment could work if you aren’t actually going to do it. The truth is that while all of these features are really nice, there are a lot of applications out there that get by without them. Even so, I’d love to give it a shot.


  1. A lot of our more recent (internal facing) apps are very Javascript heavy. More precisely, almost the entire program is written in Javascript running in your browser, talking to a thin XML web interface into a database and some backend processes.

    Automated testing this sort of thing is difficult. Got any pointers?

  2. The test framework I see most for that sort of thing is Selenium:


  3. A year ago I was lucky enough to walk into a work situation that had all of this set up already. I cannot imagine living without it ever again. The gratification you receive from releasing bug fixes in minutes instead of days is totally worth it – although any long running schema migrations or major rollouts of new features we still usually do during a maintenance window at night. The most labor intensive part of this is making sure your tests are comprehensive and keeping them up to date 🙂

Leave a Reply

Your email address will not be published.


© 2024 rc3.org

Theme by Anders NorenUp ↑