DevOps Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans

Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Digg is Using Continuous Deployment. To Deploy to Production.

07.28.2010
| 14957 views |
  • submit to reddit

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?

Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

David Bland replied on Thu, 2010/07/29 - 11:51am

I also suggest checking out IMVU and Flickr as they are pushing the envelope for continuous deployment to production.

Update: Nevermind you are already on the right trail with those external links to Eric Ries #leanstartup inspired stuff!

Lincoln Nascimento replied on Thu, 2010/07/29 - 2:51pm

Interesting article. But a question came up to me...what about the tests performed by "real testers"...sometimes a minor piece of code can cause big problems.

Jared Richardson replied on Thu, 2010/07/29 - 3:31pm in response to: Lincoln Nascimento

Not every product is well suited for this type of automated deployment, but in this case it's a server product with a well-known interface. That makes it much easier to automate more and more of the acceptance tests. However, I'd never try to replace all my testers with automated scripts. That's something I consider to be a novice mistake. If someone suggests replacing all their testers with automated tests, they've usually (in my experience) just discovered automated testing, have no experience with it, and just trying to save money. All that being said, reducing the feedback loop for a developer, from code to running on a server, even if it's an internal staging server, is invaluable. Also, an internal, constantly updated staging server is a great place for human testers to verify new features or bug fixes.

Xebia Labs replied on Mon, 2010/08/09 - 9:26am

Hi Jared, nice article. It’s great that Digg is thinking of new methods to increase productivity. I’m sure that continuous deployment will help. However, continuous deployment also comes with the risk of overwhelming IT operations teams, and can result in a backlog of applications. Do you know if Digg is using tools to help them handle continuous deployment beyond the development side, such as deployment automation software for operations?

Jared Richardson replied on Fri, 2010/08/27 - 8:18pm in response to: Xebia Labs

I don't know if they do, but your points are ~exactly~ what CI and CD expose. By eliminating one bottleneck, we always find the next one. If you're updating your database schemas by hand, it'll become obvious. If you're still deploying your code to servers by hand, this will make it very painful. Manual testing? Ditto.

Your options? Automate or work a lot of overtime. :) I prefer to automate. Tools like Liquibase, Capistrano, Rake, and others are great for solving these problems. Find a way to automate deploys, first to a continuous deployment server, then to a staging server, then, after you've got some experience with the tools and process, you deploy to a production server with an automated script. It's not trivial, but with a good test suite, it can be done. And it'll dramatically change the way you view your development and deployment life cycle.

Agile tools don't always solve problems, but they always expose them.

Xebia Labs replied on Wed, 2010/09/01 - 10:21am

Excellent point; and exposing the problem is half the battle! You mention some good products that begin to address complete automation of deployment processes and Deployit is another that can complement or work in conjunction with these tools to help get rid of such manually impossible tasks while bridging the gap between development and operations teams. Hopefully more companies will choose to automate as these issues are revealed, otherwise, that would be a lot of overtime work! ;-) www.xebialabs.com

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.