Continuous Delivery Vs. Continuous Deployment

Many people are actually confused by the terms continuous delivery and deployment. Although this confusion may cause no harm if everyone involved in the conversation is talking about the same thing, it might extremely important in relationship with someone that actually has a clue about the difference between them. Since the difference implies a to do or not to do deployment automatic deployment in production, it can go catastrophic. Oh well, not catastrophic. Bad. It can go really bad.


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.

While continuous deployment implies continuous delivery the converse is not true. Continuous delivery is about putting the release schedule in the hands of the business, not in the hands of IT. Implementing continuous delivery means making sure your software is always production ready throughout its entire lifecycle – that any build could potentially be released to users at the touch of a button using a fully automated process in a matter of seconds or minutes.

Continuous deployment is the next step of continuous delivery: Every change that passes the automated tests is deployed to production automatically.This 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.

So when can you say you’re doing continuous delivery?

I’d say it’s when you could flip a switch to go to continuous deployment if you decided that was the best way to deliver value to your customers. In particular, if you can’t release every good build to users, what does it mean to be “done” with a story? I think at least the following conditions must apply:

  • You have run your entire test suite against the build containing the story. This validates that the story is delivering the expected business value, and that no regressions have been introduced in the process of developing it. In order to be efficient, that means having comprehensive automated tests at the unit, component and acceptance level.
  • The story has been demonstrated to customers from a production-like environment. Production-like means identical with production, within the bounds of reason. Even if you’re deploying to an enormous cluster, you can use a technique like blue-green deployments to run a different version of your app in parallel on the production environment without affecting users.
  • There are no obstacles to deploying to production. In other words, you could deploy the build to users using a fully automated process at the push of a button if you decided to. In particular, that means you’ve also tested it fulfills its cross-functional characteristics such as capacity, availability and security. If you’re using an SOA or you have dependencies between your application and other systems, it means ensuring there are no integration problems.


  • Pingback: Tomcat 7+ Parallel Deployment » Programming Bytes()

  • Jesse Adelman

    I just want to say thank you for this awesome article. You’ve written up an entire career here. I was able to use the git submodule cookbooks method at two of my recent positions, and the ease of it was amazing. Combined with Test Kitchen and friends, it’s a smooth pattern.

    Jesse Adelman
    San Francisco, CA
    Systems Engineer (DevOps)