Continuous Delivery is Not Always Continuous Deployment
At Merge 2013, I heard a lot of fascinating talks from Perforce partners and customers about how they’re approaching their build and release automation. A lot of our customers are tackling continuous delivery – but this doesn’t mean they’re practicing continuous deployment.
Continuous deployment was really pioneered by SaaS firms that need to push multiple production releases every day in order to be competitive. Netflix and Facebook are prominent examples, and Perforce’s hosting partner Assembla has written about this topic extensively on their blog.
Examples like that may lead you to believe that if you’re not a SaaS company then continuous delivery isn’t for you. But don’t confuse the terminology. Anyone can practice continuous delivery and see a marked increase in quality and time to market.
Continuous delivery means that we treat every commit as a possible release candidate and vet it at successively more rigorous stages of a deployment pipeline. The pipeline goes as far as possible towards actual delivery, meaning that we’re exercising all the parts of the system frequently. A bug fix may go through pre-flight unit testing, official build and unit test, component integration test, user acceptance, staging release, and production release. Each of these stages is more difficult and requires more resources, so we weed out the commits that won’t make the cut as early as possible.
If you are working on a SaaS product--like the Massive Multiplayer Online (MMO) games that are built on Perforce--then your pipeline may indeed be fully automated and result in a push to a production server. That’s continuous deployment.
But if you work on a product where your software has to be tested in 50 different hardware devices, then the component integration test may take a week. If you work in financial services, user acceptance test may require human sign-off. If you follow ITIL standards (or just don’t want the Ops team to hate you), then that final push to production often requires a human in the loop. And ‘delivery’ may mean putting software on an ftp site or handing it off to a partner.
There’s nothing wrong with any of that, and you’re still practicing continuous delivery if you fall into any of those categories. Continuous delivery just means that we treat every commit as a release candidate, automate whatever we can within the bounds of our business, and have as much confidence as possible that we are ready to ship the latest changes when appropriate.