Digg is Using Continuous Deployment. To Deploy to Production.

I recently stumbled across an amazing article. I've been using continuous integration for years, and I've used continuous deployment for a long time, but I've never tried this trick. The clever developers working on the very popular Digg.com site are using a continuous deployment system to push out new code to one of their sites.

Why is this amazing? A continuous integration system compiles and tests your code after every code commit. That alone is a huge boost to any development team. A continuous deployment system then, as the name implies, deploys the compiled code to a server. However it's usually a staging box or a server in a test bed. These guys have gone one further and are deploying their code to the production web site after every compile.

This takes courage. And a great test suite.

If the thought horrifies you, take a moment and read the article.

Continuous Deployment, Code Review, and Pre-Tested Commits on Digg4

From the article:

One of the exciting things, from a development perspective, about Digg4 is continuous deployment - when developers fix a bug or add a new feature, there's no need to wait for a scheduled release. Instead, the change can go live right away. This is great - the turnaround time for a change drops dramatically. 

This is not unique to the Digg team either. Here's another article, with five tips for building your own continuous deployment system.

Continuous Deployment in Five Easy Steps

And a quick search of the internet easily finds results like this one as well. 

Case Study: Continuous Deployment Makes Releases Non-Events

Like many other methods that reduce a development team's feedback loop, continuous deployment won't solve any problems your team has, but it will certainly expose them. Is your team short on meaningful automated tests? This will expose it. Does your team check in code that doesn't work yet? How about an unstable build process? Check.

Continous deployment will shine a light on your build process and automated testing efforts.  If you can stand the light, you'll have a much more robust and stable system shortly. I wouldn't suggest you move your team directly to a production deploy though. Start with an internal staging server. Whenever you find a problem in your code, cover it with a test! (Defect Driven Testing anyone?) When a script fails, dig in find out why, then fix it.

What have you done with continuous deployment?