Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The Blurred Line Between CI and CD

DZone's Guide to

The Blurred Line Between CI and CD

Confusion between CI and CD shouldn't exist. You can align the high-cadence CI process and low-cadence CD process to create stable, resilient, high-performance pipelines.

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

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.

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook

Topics:
continuous delivery ,continuous integraiton ,release automation ,devops

Published at DZone with permission of Benny Van de Sompele, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}