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,
ps Early bird registration ends soon for my Agile Project Management workshop in San Jose on March 23.
A recent story on InfoQ continues this topic:
http://www.infoq.com/news/2010/01/continuous-deployment-trenches
Posted by: Chris Sims | January 31, 2010 at 09:13 AM