Published on 30 August 2013 by

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

Share via:

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".

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!

The focus of Continuous Delivery must be on Efficiency of the delivery process and Quality of working Software. And the focus of Continues Deployment must be on the frequency and speed of the deployment of working software on production.

From Business users perspective, there is no value addition if we deliver low quality working software with frequent deployments on production and reverse is also true. That is, there is no value addition if we are not frequently delivering quality working software into the production. Hence the right balance between Quality of Working Software and Speed of Deployment is required.

Hence using Continuous Delivery , we can focus on building quality working software and making the delivery process more repeatable with maximum automation and using the Continuous Deployment, we can focus on increasing the frequencies to release on to the production based on the business needs.

Much more important than the difference between Continuous Delivery vs. Deployment is the difference between Deploying en Releasing. Decoupling these two is what enables the business to make functionality available to users whenever they want to. As stated in the article, feature toggles make this possible. And yes, there are cases where this does not work. I'd say that only in those cases the difference between both CD's is important! 

Continuous Delivery Vs Continuous Deployment , I did a lot of study on this just to figure out the difference , and finally concluded that continuous delivery means that you product is always ready to be deployable to production systems , it is increasing the confidence that your software is production ready. Continous deployment is the same as described above , fully automated pipeline from start to deployment. So one thing you can think of here is the pull vs push model. In Continuous deployment you keep on pushing to production continously , in continuos delivery , it is production ready that can be pulled to production systems any time. 

Published in 2013, this is still one of the best explanations of the difference between in Continuous Delivery and Deployment, especially the process visualization (although it looks like Yassai Sundman gets the credit for the graph). We have even made our own variation for a blog post illustration:

However, the conclusion from the article should be that CI/CD should be an essential part of every developer's workflow, ideally supported with proper tooling.

Thank you for sharing! I think it's so important to clearly outline the difference between continuous deployment, continuous development, continuous integration, and continuous delivery along with the benefits to your product's quality (but also the cons/resources required). I'll be adding this to my reservoir of resources along with this guide that's been helpful:

Please, stop telling people that "continuous deployment" is the automation of "continuous delivery". This is simply not true.

The definition of Jez Humble clearly states that the aim of Continuous Delivery is "to put the release schedule in the hands of the business, not in the hands of IT". -- This has nothing to do with "manual" or "automatic". Giving business the power to release whenever they want is much harder than making things happen automatically. Try it to understand!

Continuous deployment is a technique, Continuous Delivery is a concept. If we try to compare the two we're comparing apples with bananas. One is "automate releasing software changes", and the other is "Agile software development" (see the first principle of the Agile Manifesto [¹]).


Hello there,

we are moving from continuous delivery to continuous deployment but we are facing some frictions regarding demos. Using continuous deployment systems makes the Sprint demo a bit awkward as demoed features have been already deployed on production Did any of you faced this kind of issues? Do you deploy to production without PO validation?

Best regards.

Hello, Ignacio! Many people put in feature flags for new features that are deployed to production. The features can be turned on for sprint demos and when the business is ready, the features are turned on for all customers (or even a few customers for further user validation). That way you know the feature is deployable because it's already been deployed! Remove the feature flags in the following sprint so you don't add to tech debt.

The content of this field is kept private and will not be shown publicly.

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.