The Blurred Line Between CI and CD

I have the pleasure of meeting many people in a variety of European organizations in the Continuous Delivery domain. A topic that comes back repeatedly during our projects is the confusion amongst release management stakeholders on the difference between Continuous Integration (CI) and Continuous Delivery (CD).

Let’s be fair — the tools and solution vendors are not making it easy. With CI tools claiming they deploy straight into production and CD tools claiming to cut back your build cycle times, it is easy to get confused.

Let’s try to clear up the confusion by taking a look at one of the core requirements for each domain. 

Continuous Integration 

Continuous Integration is a process that should happen as soon and often as possible in the development cycle. After all, you want to know ASAP if the code changes applied by a development team member have broken the build. If so, you’ll want to fix the issue right away. This is the core purpose of Continuous Integration. It can happen several times a day — or even several times an hour. That is why there is a lot of ongoing effort involved in reducing CI cycle time and making the CI scope as focused as possible based on the code change(s) that happen.

Continuous Delivery 

Continuous Delivery is a process that should happen as soon and as often as it is relevant. It should pick up the release candidate components from multiple development tracks, group them together, ensure functional and technical dependencies are met, and only then push that “release candidate” through the various stages of the CD pipeline. 

That blurred line between CI and CD should not be there. CI ensures you produce output (artifacts) many times an hour from many teams in parallel. CD puts the output of different CI tracks in the context of a release and orchestrates the promotion of that release package throughout the relevant stages and required tollgates.

You can align the high-cadence CI process with the lower cadence CD process to create stable, resilient, and high-performance end-to-end release pipelines.

Organizations that can successfully align their high-cadence CI process with the lower cadence CD process achieve a much more stable and resilient end-to-end process than those organizations who try to force the CD process to run at the same frequency of the CI process. That is why a CI tool is typically not a CD platform. CI and CD have different scopes, objectives, and requirements, and therefore should not be categorized together.

There is no blurred line between CI and CD. On the contrary, defining a clear demarcation point between CI and CD is one of the key success factors for implementing high-performance, scalable, and resilient end-to-end release pipelines.