1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

The Difference Between Continuous Integration and Continuous Delivery

If you’ve spent any significant amount of time in the world of DevOps and Agile software development practices, you’ve likely encountered the terms Continuous Integration (CI) and Continuous Delivery (CD). For several years, I’ve had these terms thrown around me during the course of my work as a consultant, and while I had a decent enough feel for what they meant, when it came down to actually providing definitions for the two I started having trouble. While the two practices are distinct, they’re very much related and depending on the type of software product you are producing there can be some overlap. That said, my goal here is to put forth a reasonably concise definition of each for my own understanding as well as the reader’s.

Both CI and CD find their origins from within the 12 principles behind the Agile Manifesto—specifically the 1st, 3rd, and 7th:

1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
7) Working software is the primary measure of progress.

CI is the practice of having team members integrate their work into the main repository frequently, with a preference for multiple integrations per day. The goal is to provide rapid feedback in order to minimize the cost of fixing errors. Rapid feedback is achieved when code submissions trigger an automated build and test cycle in order to detect errors and notify all relevant parties. The team needs to know not only that new changes work when checked against the mainline, but that they work with changes other team members may have submitted concurrently, thereby keeping the mainline codebase stable. This relates to the concept of working software being the measure of progress.

Although this is debated, CD is considered by many to be the next logical step following CI. With CD, the main objective is keeping your product in a state where it is always able to deploy into production. CD takes into consideration not only the code as it evolves, but the infrastructure and configuration as well. This isn’t to say that every committed change goes immediately into production. Instead, it means that following each validated change, your product is in a position such that it could be deployed into production, if necessary. This allows organizations to manage the deployment of their product based on business needs, instead of technical constraints. For instance, releasing an update earlier than originally planned in order to keep pace with a competitor. Or avoiding a scenario in which a planned release is delayed due to significant bugs.

As mentioned earlier, the type of product being created can lead to these two practices being either very similar or very different. A large organization working on a product consisting of multiple software and system components will have very distinct activities for CI and CD. Generally speaking, the software changes for a given module will need to be checked against the existing code, the module itself will need to be validated against the other modules, and the resulting software product will need to be checked for compatibility with the system level components.

For a smaller product, such as and API or a simple web application, the act of integrating code changes into the mainline repository may be all that’s necessary to keep it “deployment ready”.

In conclusion, CI is meant to keep your software modules functioning cohesively at a base level through rapid feedback, while CD focuses on the state of the final product to ensure it is always capable of being released.

David Hubbell
Software Engineer
SPK and Associates

Next Steps:

Latest White Papers

Atlassian Cloud: Understanding Zero Trust Security

Atlassian Cloud: Understanding Zero Trust Security

Where To Start & Why It Matters What is the Atlassian Cloud Zero Trust Security model? Well, for decades, enterprise security controls were built to protect a large, single perimeter around a corporation. Often described as castle-and-moat security, This approach...

Related Resources

Top 6 Ways To Improve Your DevOps Journey

Top 6 Ways To Improve Your DevOps Journey

Knowing how to improve DevOps can be challenging. But, creating an integrated DevOps toolchain can set organizations apart from the rest. This is because having a well-defined business DevOps journey can reduce errors, improve collaboration and drastically increase...

Use Nessus To Harden Your Cybersecurity

Use Nessus To Harden Your Cybersecurity

Cybersecurity should be baked into the onset of IT and product development processes. Additionally, treating cybersecurity as an afterthought opens your organization up to vulnerabilities and risk. Therefore hardening your IT product cybersecurity with a tool like...

2022: The Year So Far Tech Review

2022: The Year So Far Tech Review

There’s been a lot of innovation, software and product releases in the past six months alone. So, we are rounding up the best tech review and engineering releases for the first half of 2022. The tech forecast for 2022 was heavily influenced by how the world adjusted...