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:
- Contact SPK and Associates to see how we can help your organization with our ALM, PLM, and Engineering Tools Support services.
- Read our White Papers & Case Studies for examples of how SPK leverages technology to advance engineering and business for our clients.
