Continuous Delivery Vs. Continuous Deployment: What's the Diff?

I tweeted this out around the middle of the day last Wednesday. It kicked off an active conversation on Twitter, and by 5:00 Thursday, it had been retweeted 87 times, and favorited 25 times.

Continuous Delivery:
What It Is & How to Get Started

Free Ebook: Continuous Delivery: What It Is and How to Get Started

» Smoother deployments.

» Happier teams.

» A more agile business.

Clearly, it’s a hot topic, and there’s some confusion between continuous delivery and continuous deployment. It’s worth spending a few more characters than Twitter allows to define these terms.

Continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment and ensuring business applications and services function as expected through rigorous automated testing. Since every change is delivered to a staging environment using complete automation, you can have confidence the application can be deployed to production with a push of a button when the business is ready.

Continuous deployment is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically. Continuous deployment should be the goal of most companies that are not constrained by regulatory or other requirements.

There are business cases in which IT must wait for a feature to go live, making continuous deployment impractical. While application feature toggles solve many of those cases, they don’t work in every case. The point is to decide whether continuous deployment is right for your company based on business needs — not on IT limitations.

While continuous deployment may not be right for every company, continuous delivery is an absolute requirement of DevOps practices. Only when you continuously deliver your code can you have true confidence that your changes will be serving value to your customers within minutes of pushing the "go" button, and that you can actually push that button any time the business is ready for it.

Learn More


Allan Ebdrup

Allan Ebdrup

Seems there is still confusion. What you are calling Continuous Deployment would be, as far as I have understood it, what Jez Humble and David Farley call "Continuous Release". In their book

As an example hardware companies can to Continuous Deployment (to a piece of test-hardware) and that can help them a lot, even though they only release a new piece of hardware once a year.

For example a SaaS web-application automatically deploying to production (as in your illustration), would be doing "Continuous Release".

Sune Fischer

Sune Fischer

The confusion seems wide spread, even Fowler tends to call it "deliveries to production":
Whatever the name though, I think you'd want to deploy/release to a staging or test environment even if you do not go all the way to production. This will not only test your release package but also enable further acceptence tests which should be part of the automated pipeline setup.
Maybe we should call it "Continuous Production Rollouts" or something with the word production in it.



The source of the confusion is that your label does not encapsulate your concept. "Continuous Deployment" implies that you are continuously deploying, which you are not. "Continuous Release," as defined in the prior comment, suffers from the same problem as you are not continuously releasing your code, you are just reducing the number of buttons you push when you're ready.

Why not call it what you really mean? Something along the lines of "Continuously Production Ready"? The key idea being that you are always production _ready_, but not necessary headed to production at the moment. It even gives you a nice initialism of "CPR" -- Put your development cycle on CPR!



best advice is to just define what terms mean with your client. who cares what it's called as long as you get what you expect.

Leave a comment