Digg is Using Continuous Deployment. To Deploy to Production.
Join the DZone community and get the full member experience.Join For Free
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.
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.
And a quick search of the internet easily finds results like this one as well.
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?
Opinions expressed by DZone contributors are their own.