Continuous Delivery Vs. 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.  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.”

So, in a nutshell, continuous delivery could have been called continuous application life-cycle management, but that makes for a very long name. 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. Continuous delivery engines are orchestration solutions.  They connect and control all the steps needed to track the life cycle of an update, calling on external tools to perform the steps. From a tool perspective, continuous delivery engines are the foundation of the continuous delivery process. In contrast, the job of continuous deployment is to automate one step in the overall CD process, the release.

A Quick History Lesson

Understanding continuous delivery vs. continuous deployment requires a look back.  Let’s first look back at how we got here. It all started with continuous integration (CI), the practice of “merging all developer working copies to a shared mainline several times a day.” Once the merge was completed, an automatic check-out of the code was performed, and then 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.  Everything was scripted. The build was scripted, as was the copy to the server.  Developers could rely on the CI triggers with their version control tool to execute this process and find out early on when the build broke, or if the new build was a bad one at run-time. The goal was to create a process that allowed problems to be found early and builds to be fixed within “10 minutes.”

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, and that 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 didn’t want to rely on the developer scripts that were created for the CI process. They need more; more transparency, more reliability and far less risk. This is what drove the need for continuous deployments managed by release automation tools.

It has taken us a while to come to an understanding that deployment scripts, created for a development or test environment are just not robust enough to do the heavy lifting required by production teams. Production teams have more to worry about, such as database updates, rollbacks, jumping forward, infrastructure, environment variable settings, not to mention the standard stack needed on all endpoints.  And a real showstopper for production teams was the need for yet another agent on all the endpoints required by the CI/CD engine to run the scripts. Agentless continuous deployment (release automation) tools address these requirements and ensure that a release is performed exactly the same way across all environments, dev through prod.

Let’s look at an example using CircleCI and DeployHub  

CircleCI supports a full continuous delivery pipeline. It enables an open architecture that supports the calling of any tool to perform the required steps of the life cycle process.  Another job of CircleCI is to aggregate all log information from the external tools it calls so users have a single source of information for tracking an update across the life cycle.  This in fact is a huge benefit to end users and a core function of CD.


CircleCI and DeployHub

DeployHub is a microservice management platform that supports deployment features for both monolithic releases and microservice releases (independently deployable functions). Continuous deployment is the one step of the continuous delivery pipeline that is common to all stages.  A deployment must be done in development so developers can run their unit testing, in QA for more robust system testing, and of course in production to deliver the changes to end users.  Using the same deployment process across all stages in effect performs a ‘test’ of the deployment prior to a production release. CircleCI calls DeployHub to do the deployment across all stages and centralizes the deployment logs as part of the workflow processing.

 Benefits from adding Continuous Deployment to CD

There are a good reasons why you’d choose a continuous deployment solution over your deploy scripts to perform software releases across the life cycle. First, Mapping and Versioning. DeployHub puts the application back into a microservice architecture to map and track software updates overtime.  Applications and components have versions. With DeployHub’s versioning capability, you can do incremental deployments to move away from the old style monolithic approach and get ready for a microservice pipeline. If you are just updating a .jar or .war file, you can always just copy the new file over. We agree that a script can do that, but an application is more than just a binary, and a deployment is more than just a copy.  With DeployHub, you can include in your package as a deployment:

  • Database updates
  • Environment variables
  • Binaries
  • Microservices
  • Infrastructure changes

And unlike a simple copy, your full stack deployment package can be rolled forward, rolled back, or it could even jump versions. So when production is five versions behind and you want it up to the most recent release, DeployHub does that incrementally (including the database updates), reducing the time and risk associated to the release. DeployHub’s reports show what has changed by providing an audit trail which makes even the grumpiest production control team happy. And finally, let’s mention your value stream. DeployHub reports the full process the change has gone through, from the original request to where it was released. We call this a continuous feedback loop, showing you how long it took to deliver the new innovation to your end users.

value stream


Leave a Reply