Continuous Integration vs. Continuous Deployment
March 30, 2023

Matthew Casperson
Octopus Deploy

The terms "Continuous Integration" and "Continuous Deployment" tend to be combined into the acronym CI/CD to describe the process of building and deploying software, often without distinction between the two. The terms describe distinct processes, even if combining them suggests that Continuous Delivery and Continuous Deployment are an extension of Continuous Integration, and the execution of both processes is the responsibility of a single tool.

Build with GitHub. Deploying with Octopus.

Assuming CI/CD is just CI with a deployment step ignores some fundamental differences between the two processes. In this blog, we look at:

■ The reasons why CI and CD are distinct processes

■ The features provided by good CD tools

■ Why you may consider using separate tools for your CI/CD workflow

What is Continuous Integration?

At a high level, Continuous Integration tooling is concerned with:

■ Taking the code written by developers and compiling it into an artifact

■ Running automated tests

■ Capturing the log files so any failed builds or tests can be resolved

A Continuous Integration server facilitates this process by running builds and tests with each commit.
Continuous Integration servers can be described as solving the equation:

code + dependencies + build tools + execution environment = test results + logs + compiled artifact

The left side of the equation takes the code written by developers, any dependencies of the code, a build tool, and the environment where the build and tests are executed. When these inputs are available, a Continuous Integration server completes the build to produce the elements on the right side of the equation.

When a Continuous Integration server has been configured correctly, each commit to a repository results in the build being run, thus solving the equation without manual intervention from a human.

This means the process implemented by Continuous Integration servers is machine-driven, so much so that it's common for Continuous Integration servers to have read-only user interfaces, like the Jenkins Blue Ocean UI.

The other important aspect of the Continuous Integration equation is that developers provide the inputs, and the outputs are created for developers or people in other technical roles. Employees outside the IT department rarely interact with the Continuous Integration server.

What Are Continuous Deployment and Continuous Delivery?

Continuous Deployment takes the compiled artifacts from a successful build performed by the Continuous Integration server and deploys them into the production environment, resulting in a completely automated deployment workflow. In this scenario, Continuous Deployment is quite rightly an extension of Continuous Integration, and the distinction between the two becomes somewhat arbitrary.

Such commit-to-consumer workflows are common in simple projects. More complex projects can also have a completely automated deployment workflow, if the appropriate tests and monitoring systems are in place.

But while fully automated deployments have many benefits, it's not uncommon for deployments to involve human decision-making. There are many valid reasons for not automatically deploying every commit to the main branch into production, including:

■ Coordinating deployments with legacy systems

■ Acquiring sign-off from product owners

■ Usability testing that is impossible to automate

■ Regulatory requirements

■ Dog-fooding your own product

■ Integrating deployments with back-end changes like databases

■ Not having 100% confidence in your tests

The term Continuous Delivery is used to distinguish workflows that incorporate human decision-making from Continuous Deployment workflows that are fully automated.

Where Continuous Integration tooling is machine-driven for many teams, Continuous Delivery is human-driven. Much of the grunt work of performing a deployment is still automated, but the decision to promote a release through to production is a human one. Importantly, the decision may not be made by technical employees, but rather product owners, managers, or someone who stayed up until midnight to click the deploy button.

Why Use Separate Continuous Integration and Continuous Delivery Tools?

A typical CI/CD pipeline, with no distinction between the two

This slide is from a talk titled How to build cloud-native CI/CD pipelines with Tekton on Kubernetes. It's a classic example of how simple projects merge Continuous Integration and Continuous Deployment into a single process where a production deployment starts as soon as the code has been compiled.

There's nothing wrong with this process, and it works as intended if every part of the pipeline remains fully automated. But what happens if a human needs to test and approve the application before it's released?

For this decision to be made, the deployment process must be interrupted. For example, we'd first deploy the application to a test environment, allow the appropriate parties to verify the changes, and when everyone is happy, the release is promoted to production.

This single decision point means our once machine-driven equation now:

■ Requires a UI to expose the releases that have been made to the testing environments.

■ Introduces auditing and security concerns so we can limit and then review who promoted which releases to which environments.

■ Requires a UI to allow deployments to be promoted to the next environment.

■ Requires a system that can model environments in a first-class manner so they can be reliably secured and managed through the UI, API, and reporting interfaces.

Octopus dashboard with deploy buttons for humans

This focus on the human element is frequently lost when CI/CD is presented as nothing more than a deployment step, automatically performed after the code has been compiled.

A good deployment tool facilitates the human decision-making process that is so common (if not essential) to deployments, or at the very least surfaces the current state of the deployments between environments, and automates the deployment, so promotions between environments are easy and reliable.


Recognizing the different requirements between a machine-driven Continuous Integration process and a human-driven Continuous Delivery process is essential for delivering features to your customers in a fast, reliable, and repeatable manner. This is why using dedicated tools for Continuous Integration and Continuous Delivery can make sense.

You can give it a try by building with GitHub and deploying with Octopus.

Matthew Casperson is Principal Content Engineer at Octopus Deploy
Share this

Industry News

June 01, 2023

Couchbase announced a broad range of enhancements to its Database-as-a-Service Couchbase Capella™.

June 01, 2023

Remote.It release of Docker Network Jumpbox to enable zero trust container access for Remote.It users.

June 01, 2023

Platformatic launched a suite of new enterprise-grade products that can be self-hosted on-prem, in a private cloud, or on Platformatic’s managed cloud service:

May 31, 2023

Parasoft announced the release of C/C++test 2023.1 with complete support of MISRA C 2023 and MISRA C 2012 with Amendment 4.

May 31, 2023

Rezilion announced the release of its new Smart Fix feature in the Rezilion platform, which offers critical guidance so users can understand the most strategic, not just the most recent, upgrade to fix vulnerable components.

May 31, 2023

Zesty has partnered with skyPurple Cloud, the public cloud operations specialists for enterprises.

With Zesty, skyPurple Cloud's customers have already reduced their average monthly EC2 Linux On-Demand costs by 44% on AWS.

May 30, 2023

Red Hat announced Red Hat Trusted Software Supply Chain, a solution that enhances resilience to software supply chain vulnerabilities.

May 30, 2023

Mirantis announced Lens Control Center, to enable large businesses to centrally manage Lens Pro deployments by standardizing configurations, consolidating billing, and enabling control over outbound network connections for greater security.

May 25, 2023

Red Hat announced new capabilities for Red Hat OpenShift AI.

May 25, 2023

Pipedrive announced the launch of Developer Hub, a centralized online app development platform for technology partners and developers.

May 25, 2023

Delinea announced the latest version of Cloud Suite, part of its Server PAM solution, which provides privileged access to and authorization for servers.

May 24, 2023

Red Hat announced Red Hat Service Interconnect, simplifying application connectivity and security across platforms, clusters and clouds.

May 24, 2023

Teleport announced Teleport 13, the latest version of its Teleport Access Platform to enhance security and reduce operational overhead for DevOps teams responsible for securing cloud infrastructure.

May 24, 2023

Kasten by Veeam announced the release of its new Kasten K10 V6.0 Kubernetes data protection platform.

May 23, 2023

Red Hat announced Red Hat Developer Hub, an enterprise-grade, unified and open portal designed to streamline the development process through a supported and opinionated framework.