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

Three Trends Are Transforming The Service Desk

Three Trends Are Transforming The Service Desk

Your IT service desk is about to change. Find out what's shaping the future. Three factors — enterprise service management (ESM), collaboration, and intelligent service management — are driving the transformation of the service desk. To better meet customers’ needs...

Related Resources

10-Point Checklist for Atlassian Server Migrations

10-Point Checklist for Atlassian Server Migrations

Introduction As applications, such as Jira, become more mainstream for Enterprises, it was inevitable that Atlassian and others would create their own service (SaaS) that provides numerous benefits to users across the globe.  The benefits of having a SaaS...

What is DevOps?

What is DevOps?

https://www.youtube.com/watch?v=e1aXoYaWReY Introduction Hello and welcome to what is DevOps? So in this video we're going to talk through not just the book definition of DevOps but I'm going to give you some examples of how DevOps is applied in an organization and...

SPK’s vCAD Solution Increases Productivity, Security, and Savings

SPK’s vCAD Solution Increases Productivity, Security, and Savings

SPK helps a tech manufacturer to increase security and availability of its CAD systems and data by moving them to the cloud—while helping them to save $30k per year.   The Client A well-known maker of power distribution units for IT racks and related equipment...