james mckay dot net
because there are few things that are less logical than business logic

Continuous Deployment: radical idea or April fool?

No doubt many of my readers will be aware of the concept of Continuous Integration. It takes daily builds one step further by building your project every time you check in some code, running all the unit tests, creating your packages, and generating some reports. It means that if you break the build, you get fairly quick feedback on the fact. Continuous Deployment takes this even further still, by automatically deploying every successful build to your live production environment.

Now perhaps it’s just coincidence, but I first came across the concept of Continuous Deployment yesterday morning when I saw this headline from Simon Willison pop up in Google Reader — on April Fool’s Day of all days. However, clicking through to the article he linked to led me to a couple of blog entries written back in February, and a Google blog search turned up several dated hits indicating that this isn’t a joke concept that was churned out just for the day, like the old classic about Swiss spaghetti harvesters. Believe it or not, apparently some people are actually running automated deployments to their live production environment of every last check-in.

But is it a good idea?

Well let’s just say it has that kind of radical, crazy startup feel to it. It’s the kind of thing that you do to prove to lesser developers that you’re in a completely different league to the rest of us, and then everybody else tries to copy you and falls flat on their face because it doesn’t work in their situation, or they’ve completely misunderstood you, or they haven’t done it properly in the first place. Either that or else as link bait — a bit like Joel writing his own compiler, or Paul using Lisp for everything.

I guess you could get it to work, if you have the right kind of team, the right kind of processes and the right kind of people working on it. But in effect, you are doing away with your QA and change control processes altogether, and relying entirely on your unit tests as a substitute. I don’t think much of this idea at all myself. Unit tests have their limitations: they can only ever cover a tiny fraction of the possible use cases for your code; making a change to one part of your system often introduces a bug in another part of the system that your unit tests hadn’t foreseen; there are things that it is very difficult to test properly through unit tests, such as user interfaces or external services; and your unit tests themselves may have bugs and be testing the wrong thing anyway. You just have to have them backed up by some manual ad-hoc testing to find more possible ways that issues could crop up.

You could of course — and indeed probably should — deploy continuously to a SAT or UAT environment: that way, your internal testers can evaluate changes fairly quickly and you can adopt a truly agile approach. However, deploying continuously to your live production environment sounds pretty reckless to me. I’m still tempted to call April Fool on this one.


  • # Reply from Hardip Singh at 22:09 on 3 Apr 2009

    I am working on a project now where we recently setup with CI. For con’t buillds, we look for modifications every 1/2 hour and if modifications are detected, we build the code and run unit tests. We also recently added in continuous deployments. The continuous deployments do not occur as frequently though. We have the deployments scheduled for every midnight (off work hour for most). There were 2 drivers that made us setup our CI environment to do deployments.

    1) We have an entire suite of functional (selenium) tests that we run against our entire web app after a deployment is complete. The automated deployments not only gives us insight into whether or not anyone broke the build/deployment, but also gives us the ability to automate functional tests against our app.

    2) Having deployments inside of our CI environment allow for a one button deployment system which is a lot better than our previous mechanism.

    If we had dedicated app servers that we can deploy code to more frequently w/out disrupting any testing that would be going on, I would do the deployments more frequently. For now though we are deploying to environments that are also used by QA / Product folks to do their testing.

    I do agree that in some situations Con’t deployments don’t make sense, but in our case, I feel that they did.

  • # Reply from Hardip Singh at 22:13 on 3 Apr 2009

    Sorry, I meant to add that I agree that unmanned deployments to a live environment is pretty risky. I definitely would not do that for our app. The ability to do a push button deployment and run some smoke tests against the live site is a good idea IMO though.

Comments are closed.