Skip to main content
Differences Between Continuous Delivery Vs. Deployment

Differences Between Continuous Delivery Vs. Deployment

By 06/21/2019December 2nd, 2022Continuous Delivery

Knowing the difference between continuous delivery and continuous deployment

Continuous delivery vs. continuous deployment, a common question in DevOps circles. I often hear, “Aren’t continuous delivery and continuous deployment the same thing?” Good question. The answer is, yes, there is a difference between the two.

As defined by the CD Foundation, “CD is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time. The rise of microservices, cloud-native architectures, has caused a corollary rise in continuous delivery practices. This is related to CI/CD that includes Continuous Integration (CI) — the practice of merging all developer working copies to a shared mainline several times a day.”

What is the Difference Between Continuous Delivery and Continuous Deployment?

Continuous Delivery:

Continuous delivery is the process of managing a source code change from change request to production release and everything in between. And there is a lot to manage.

In a nutshell, continuous delivery could have been called continuous application life-cycle management, but that makes for a very long name.

Continuous delivery engines are orchestration solutions. They connect and control all the steps needed to push an update, calling on external tools to perform the steps. From a tool perspective, continuous delivery engines perform a job scheduling function.

Continuous Deployment:

In contrast to continuous delivery, the job of continuous deployment is to automate one step in the overall CD process, the release.

Now add a cloud-native architecture to the puzzle. Keeping track of small independent microservices, deployed independently, disrupts our entire continuous delivery process. This disruption has created the rise of the microservice ‘service’ catalog and declarative deployment methods such as GitOps to support a new kind of pipeline.

A Quick History Lesson

Understanding the differences between continuous delivery vs. continuous deployment requires a look back.

It all started with continuous integration (CI), the practice of “merging all developer coding updates to a shared mainline several times a day.” Once the merge was completed, an automatic check-out of the code was performed and a build script was called to create the binaries.

These binaries were copied to a server to be tested. CI was executed by the developers for the developers. Developers could rely on the CI triggers with their version control tool to execute the ”build’ process and find out early if the build had compile problems or runtime link errors.

The goal was to create a process that allowed the build to be fixed within “10 minutes” and thereby maintaining a healthy ‘binary’ release candidate. Everything was scripted and executed in an ‘imperative’ way.

Once the developers had a process that was working for them, they wanted to push the new update to the testing team. In essence, one CI workflow needed to call another CI workflow. This need was the birth of continuous delivery. We no longer simply automated what developers needed in a Dev CI workflow, we wanted testing and production to be part of the automation as well.

As teams across the enterprise started using the new automated process with more features, reporting and visibility was required. Testing teams wanted their test scripts executed during the ‘test’ CI workflow which began the conversation around ‘continuous testing.’ And when the process hit production, production didn’t want to build or test, they just want to release. But they also didn’t want to rely on the developer scripts that were created for the CI process.

They needed more – more transparency, more reliability, and far less risk. This is what drove the need for continuous deployments managed by application release automation (ARA) tools. ARA tooling focuses on streamlining releases to address rollbacks, blue/green deployments, and canary releases, all specific to the needs of Production teams.

The deployment function of the Continuous Delivery pipeline continues to change. The rise of GitOps and the move to microservices changes the requirements of the continuous deployment process. New tooling in this area has evolved with the goal of establishing a consistent method of releasing updates across the continuous delivery pipeline.

When it comes to the difference between continuous delivery vs continuous deployment, the ugly truth is, continuous deployment has been a weak link in the continuous delivery process. This weakness in the CD Pipeline must be addressed as we move to a cloud-native environment where microservices are moving across the CD pipeline all day long.

Cloud-Native Continuous Delivery vs. Deployments

Unlike the past, tomorrow’s continuous delivery pipeline will need to manage hundreds of independently deployed smaller components. No longer will the CI step compile and link a fat binary.

Instead, the CI step will create take something like python code, add it to a container, and then register the container image. Linking is done via APIs at runtime allowing smaller components, like microservices, to be pushed independently across the pipeline. Microservices are the future of software development and both continuous delivery and continuous deployments will need to adapt.

Microservices with their poly databases, key value pairs, and infrastructure tweaks become more difficult to track. Imagine being on a support team and receiving a call on a microservice you know nothing about.

Continuous delivery must now include an automated configuration management step to track microservice details across multiple clusters and namespaces. Microservice continuous deployments must be 100% consistent meaning the use of imperative scripts needs to be retired. GitOps and declarative deployment methods will be key.

DeployHub, Continuous Delivery, and Continuous Deployments

DeployHub is a microservice ‘service’ catalog that addresses the tracking of microservice versions and their critical details (ownership and inventory across clusters – with versions.) It is called part of the continuous delivery pipeline at the point in time where a new container image has been registered.

DeployHub is triggered to create a new version of the container and build all dependency relationship creating Bill of Material and Blast Radius maps. It is called a second time when that container is to be deployed. DeployHub, in turn, calls the associated deployment engine (Helm for example), and tracks, where is, was deployed for a full inventory.

This level of control allows all teams, from development through incident response, to see the full picture of a microservice application and its versions.

microservice catalog

DeployHub can manage any type of component including:

  • Database updates
  • key value pairs
  • traditional binaries
  • microservices
  • infrastructure changes

DeployHub creates maps to visualize who uses a component, where it has been deployed and to re-construct a logical application that can also be tracked as an ‘application version.’

Dependency Map

Conclusion: Continuous Delivery vs. Continous Deployment

Moving to a microservice application requires many shifts. It would be a mistake to ignore how your continuous delivery and continuous deployment process needs to change. Both will need to be adapted to support a high-frequency release process of many moving parts, all with their own unique characteristics.

What we used to track in our traditional CI process will no longer be produced. Application versions, bill of material reports, and difference reports are critical pieces of the continuous deployment process. DeployHub puts those pieces back into a pipeline providing the north star we have always relied upon.

Further Reading:

Next Post
Close Menu