On Twitter and on web operations focused blogs, the concept of Continuous Deployment is a topic that is gaining momentum. Across our consulting clients, we've also seen a significant uptick in discussion around the concept of Continuous Deployment (some calling it "Agile Deployment").
The extreme example of Continuous Deployment that has sparked the most polarizing discussions is from Timothy Fitz's posts on doing production deployment's up to fifty times per day.
While it's a fascinating read, many people for whom the essay is their first exposure to the idea of Continuous Deployment overlook the real value. The value is not how Fitz gets code all the way into production on a sub-daily basis. The value is in achieving a state of continuous automated testing.
If you understand the concept of "the earlier you find a bug, the cheaper it is", the idea of continuous testing is as good as it gets. Every time a build executes, your full suite of unit, regression, user/functional, and performance tests are automatically run. In a mature operation this could quite literally mean millions of automated tests being executed every day. As your application development makes even the smallest moves forward, the application is being rigorously testing inside and out.
Another common misconception is that Continuous Deployment means that human-powered QA cycles are a thing of the past or are somehow less important. This belief is probably a byproduct of those extreme practitioners of Continuous Deployment who are doing hot deployments to production after every build. In most business scenarios there is not much benefit to continuous production deployment. The value of a human-powered QA team sensing if the look, feel, and functionality match the requirements can't, and shouldn't, be overlooked.
Most of our consulting clients just aren't interested in sub-daily deployments to live production environments. What they want out of Continuous Deployment is to have a constant state of broad automated testing and an always up-to-date QA environment for human-powered testing and business review.
In addition to deploying a broad suite of automated testing tools, Fully Automated Provisioning provides the linchpin that makes Continuous Deployment a reality.
Monday, June 15, 2009
Continuous Deployment Really Means Continuous Testing
Subscribe to:
Post Comments (Atom)
2 comments:
Hi there. You're right in that most businesses would be horrified to see as many production releases as you'd get if you were doing 'pure' continuous deployment. I guess there's a few industries where you might get away with that. For the most part it would be a huge step up for many organisations just to release every month and know what's in that release :)
We see basically zero traction for the idea of continuously deploying to production. I think that idea is confined to the pure technology organizations.
Release to production is really a business function and technology doesn't have much credibility in dictating the pace. However, continuously deploying to test environments (and automatically testing) is a technical quality control issue that technology should dictate and had every right to demand.
Post a Comment