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.

Posted at 08:00 on 2 April 2009.