Continuous delivery vs. continuous deployment is a common topic for discussion in the world of CI/CD and DevOps. That CI stands for “continuous integration” is a no brainer. But, “CD” is ambiguous in this context, making it difficult to distinguish between continuous delivery and continuous deployment. In addition, continuous delivery is taking on a new meaning, thanks to industry analysts like Gartner and the expansion of CI platforms. This post explains the difference, adds clarity to the murkiness, and explores where continuous delivery is headed next.

What Is Continuous Delivery?

Continuous delivery generally refers to the automatic preparation of code and code changes for release in production. From merging code changes to delivering builds that are ready for production, each stage in the process involves the automation of testing and code release. The code is uploaded to a source repository (think GitHub) or a container repository (think Docker). Once uploaded, automated tests such as unit, regression, and performance are run to ensure the code is of high quality. After that process is complete, what is slated for executions is deployed automatically to an intermediate environment, and it can be pushed live on-demand by the operations team. The goal is always to have code ready for deployment to a production environment.

Okay, I just said “deployment,” so isn’t this continuous deployment? The answer is no. The outcome of continuous delivery is production-ready code for deployment but not the deployment itself. In short, continuous delivery ensures that delivering code is as easy and fast as possible for operations, but it requires someone to approve and push the release or update to production.

What Is Continuous Deployment?

Continuous deployment automatically pushes tested code into production. It builds on the benefits of continuous delivery and is considered the next stage in a CI/CD pipeline. Put simply, there is no on-demand release to production, which implies human intervention; instead, the code moves from integration to release, and testing is integrated into the process.

This automation can be a boon for overloaded operations teams, and, with testing integrated into all the processes, it’s easier to catch issues and address them sooner. It also ensures there’s no lag between when a code change is validated and when it moves into live production. It’s important to note, however, that testing and monitoring are more crucial in continuous deployment because of the automatic push to production.

Tips for Telling the Difference Between Continuous Delivery and Continuous Deployment in CI/CD

When the terms are spelled out, the difference between continuous delivery and continuous deployment is pretty clear. Continuous delivery is like having a Domino’s delivery person show up on your doorstep with a pizza that you check for ingredients and quality before you put it on your dining or kitchen table. Continuous deployment is like having a Domino’s conveyor belt that regularly sends you a pizza that has been monitored from the get-go to ensure it meets all your quality, ingredient, and flavor expectations and changes.

But when a platform promises CI/CD without explanation, how do you know which CD it is? That’s the murkiness I mentioned in the introduction of this post. Here are some tips for telling the difference:

  • If the platform is described as automating the processes of building “deployable code,” it is offering continuous delivery. Examples include Spinnaker and AWS CodeBuilder.
  • If the platform is described as including testing and monitoring throughout the CI/CD process, it is referring to continuous deployment. Examples include Azure DevOps and Red Hat OpenShift.io (note that Red Hat is now an IBM company).
  • If the platform is described as continuous integration, but it also enables automating code preparation and automatic releases, it is most likely providing continuous deployment. The most famous example is Jenkins, which you can use to automate each stage in the CI/CD pipeline.
  • If there are no hot-button terms used to offer clues, it is most likely that the CI/CD platform is offering continuous deployment.

Are you sensing a theme here? Yes, the CI/CD term is a-changing.

Delivering a New Definition for Continuous Delivery

If you follow industry analysts and trends, you know that automation is everywhere, and the DevOps pipeline is absolutely no exception. The difficulty of continuous deployment in heavily regulated industries notwithstanding, current CI/CD platforms are geared more towards providing CI/continuous deployment than CI/continuous delivery. When Gartner uses “continuous delivery,” for example, they are actually talking about automating the DevOps pipeline, including deployment, and not stopping at delivering deployable code.

This transformation of the term makes sense. When we talk about “application delivery,” we wax poetic about all the steps involved in getting an app into the hands of a user or customer. Automation and the cloud are the reason we can paint the term with such a broad brush. So it’s not such a stretch to see delivery used in this context for DevOps.

In fact, as automation continues its inexorable march through DevOps, it’s possible that CI/CD will become CI/CD/CO, where CO is continuous operations. Or, I can even see continuous DevOps, which would remove all the letters and slashes, turning it all into just a simple CD. That’s an intriguing concept for sure.