What’s the Difference Between Continuous Integration (CI) & Continuous Delivery (CD)?
In this article, we take a look at Continuous Integration and Continuous Delivery to go over their differences and best practices.
DevOps, Continuous Integration, and Continuous Delivery… How many more buzzwords could we throw into the first sentence of a blog post? Odds are if you’ve spent any amount of time in the software engineering world, you’ve come across these terms. The problem is sometimes these terms are used interchangeably, when in fact they are separate disciplines.
DevOps is the umbrella concept used to describe initiatives to speed up and automate software development and delivery. Dev teams seeking to adopt DevOps practices might be trying to improve the software development life cycle (SDLC), improve the software delivery process, or reduce the amount of human intervention needed altogether. Continuous Integration and Continuous Delivery are two different methodologies under the DevOps umbrella.
What Is Continuous Integration?
Continuous Integration is a DevOps practice where developers merge and integrate their code to one central repository. Afterwards, testing automation and build automation is executed. These automated builds can be triggered by an event, such as a code change, or merge, or on a regular schedule. The end result of a build is an artifact or a release candidate, and the main goal of Continuous Integration is to build and publish that artifact for deployment.
What Is Continuous Delivery?
Continuous Delivery is the automation of steps to safely get changes into production. Releases can be highly variable and incongruent between teams. Individual teams often have their own requirements, their own tooling, and their own release schedule. Traversing all the needed steps and modifications needed to propagate/support changes or new features across a large organization can be daunting. Continuous Delivery brings together all of the testing steps, incremental/environmental deployments, and validation steps to safely get changes into production. The final goal of CD tools is to “push a button” to get changes into production. Continuous Delivery, by the way, isn’t to be confused with Continuous Deployment - we go into that in our Continuous Delivery vs Continuous Deployment article if you’re looking for the differences between the two.
Differences Between CI & CD
CI and CD go hand-in-hand and are usually confused to mean one thing - but the processes are completely separate. Continuous Integration (CI) enables software development teams and workflows to help build and test code faster. Many organizations are under pressure to deliver quickly with innovation and quality. Working with code involves developing, merging conflicts, code management, testing, contributing to long deployment lead times, infrequent deployments, and high change failure rates. The solution is to utilize CI to integrate development changes in an automated fashion, thereby improving feature development’s cadence and process.
On the other hand, Continuous Delivery (CD) enables operations teams and workflows. The goal is to safely and repeatedly deliver an artifact into a production environment. The CD process helps automate operationalizing services and involves releasing, deploying, and monitoring applications. As an artifact is promoted into production or higher environments, more rigor is added to the verification process. Adding additional tests to the testing process and into each stage or workflow for an environment allows teams to catch issues before these issues are found by customers.
How to Recognize if You’re Really Doing CI/CD
Conflating the two terms CI and CD tricks organizations into thinking that they are doing both when most of the time they are just running an extension of Continuous Integration. Running a CI server such as Jenkins or Bamboo to integrate code changes via automation and a pipeline does not mean CD is in place. To successfully engage in CD, deployments to production must be continuous as well.
How Continuous Integration and Continuous Delivery Work Together
Today, there is a focus to shift left to ensure issues are caught early on in the software delivery process. CI and CD work together to ensure organizations have the capabilities and visibility to catch and fix defects/bugs and potential production failures, or incidents that can otherwise be detrimental to a business. CI/CD pipelines act as automated delivery pipelines, mimicking the entire software development life cycle (SDLC) that otherwise can be hard to understand, improve, share, and control.
Best Practices in Continuous Integration and Continuous Delivery
CI Best Practices
Automated builds must be fast. The build process runs multiple times a day, with triggers from a source code repository. Time waiting for results can snowball and cause developer productivity to go down.
Confidence in the build and deployable packaging is different from confidence in the deployment and subsequent release. Being strategic in where to apply parts of the test suite is needed in order to avoid overburdening the Continuous Integration process. A line in the sand should be that Continuous Integration tackles artifact-centric confidence-building (for example, unit tests, integration tests, and artifact scans). Tests that take into account other artifacts and dependencies and/or application infrastructure are better-suited for the Continuous Delivery process. After the build is checked into a central repository and merged into the main branch, the next step to getting your idea into production is the promotion/deployment process.
CD Best Practices
A good CD pipeline is fast, safe, and repeatable. But there is no one-size-fits-all approach to Continuous Delivery. A CD solution needs to be flexible to meet the needs of the various teams in an organization.
It's also important to find the release strategy that best suits your organization's needs. For example, some companies will be perfectly content with a basic rolling deployment, but others might need more security from a blue-green or canary deployment.
One of the hardest stages to automate is the verification of deployments. When running a normal test, the results are binary – either it is a passed test or a failed test. Validating if a deployed application is successful or not can bring in a host of concerns and areas to check. Especially when implementing a canary release strategy with several incremental deployments, this validation can keep occurring, and should, even post-deployment. Correlating data/key metrics from different monitoring, observability, and performance management solutions can be tedious – especially when trying to determine a baseline. The Harness Platform takes the guesswork out of that scenario.
The Harness Platform allows you to have an entire end-to-end CI/CD pipeline so your code changes can reach production in a safe manner. No matter the deployment strategy, the exact steps or the tools involved, Harness can help your dev teams and DevOps teams achieve a push-button release.
This blog post was written in collaboration between Dan Lamm and Ashley Kim.