Beyond Continuous Integration: Continuous Deployment

I worked for a company that deployed their server software every day, sometimes more often than that. Over time, the system got more complicated and more prone to break when changed. The decision was made to only deploy twice a week. The reasoning was that this would give us more time to test the new build. Now we had a new problem: when we found bugs during testing it could be difficult to track down which of the many changes in the new build caused the problem. Worse yet, even when we could quickly find and fix the trouble, we had to do a whole new build and start the testing process over again.

What if we could push every new change right into production? When things went bad, at least then we would know which change was causing the trouble. What would it take to make this feasible?

  • Fast builds
  • Fast deployment
  • Thorough and fast automated tests
  • Easy and fast rollback to a previous version
  • A solid Definition of Done for all code changes

Can it be done? It is being done! Read about it in my lasted article on InfoQ: Beyond Continuous Integration: Continuous Deployment.

Cheers,

Chris

ps Early bird registration ends soon for my Agile Project Management workshop in San Jose on March 23.

This entry was posted in agile. Bookmark the permalink. Trackbacks are closed, but you can post a comment.

One Comment

  1. Posted January 31, 2010 at 9:13 am | Permalink

    A recent story on InfoQ continues this topic:
    http://www.infoq.com/news/2010/01/continuous-deployment-trenches

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>