Continuous integration / Continuous Delivery / Continuous Deployment

The terms Continuous Integration, Continuous Delivery and Continuous Deployment can still confuse. Even Jez Humble, author of the book Continuous Delivery commented that there is “confusion around the terms continuous delivery versus continuous deployment and my own thinking and definitions have changed”.(1)

This is my attempt to distinguish, based on the sources listed below.

Continuous integration

Continuous integration (CI) is straightforward, simple and cheap (James Shore described how to do it way back in 2006, using little more than a rubber chicken!). It is when you continually integrate code from all developers together. This typically goes hand in hand with trunk based development; rather than having long lived feature branches where code may be worked on in isolation for days or weeks at a time, code is integrated into the main (aka master, trunk or develop) branch frequently (e.g. at least once per day).

An automated (and ideally, fast) build is key, as is treating any build breakage as a priority. But it is also entirely possible to be using CI tools and yet not really using CI. For example you may have a tool like Jenkins automatically monitor for changes on trunk and building automatically, but if you are still using long lived feature branches that developers are working on for days at a time before integrating, you are not practicing CI. As a result, you are likely still dealing with difficult merges, and not finding out about integration problems until days or weeks after the problem code was written.

 

Continuous Delivery

Continuous Delivery is a step up from Continuous Integration. Yes, you must be practicing trunk development by regularly merging and automatically building, but the build must also be kept in a deliverable (aka releasable) state AND you must actually be able to easily delivery/release it if you choose, such as with one click deployments. In other words, Continuous Delivery means continuous integration that produces a deployable artifact AND making that artifact easily deployable.

 

Continuous Deployment

Continuous Deployment is another step up again, and the most sophisticated. Not only must you be continuously integrating and building artifacts that are easily deployable, but you should be actually using that power and regularly pushing the artifacts into production. In other words, you should be doing production releases with the click of a button, or even more sophisticated, automatically doing releases to production that have passed all or tests and checks. (Some orgs may still require some manual checks for audit purposes making completely automated releases difficult).

In terms of sophistication, it is

Continuous Integration -> Continuous Delivery -> Continuous Deployment

Less sophisticated ——————————————> More sophisticated

 

Continuous Delivery comes before Continuous Deployment, just like their alphabetical order. Continuous Delivery is a prerequisite for Continuous Deployment.

 

Sources
(1) The DevOps Handbook, by Willis; Humble; Kim; Debois

(2) Continuous Delivery by Martin Fowler

(3) Continuous Integration on a Dollar a Day, by James Shore

(4) Continuous Integration, Thoughtworks

(5) Continuous Delivery vs Continuous Deployment, crisp.se

Tags: ci, cicd, continuousdelivery, continuousdeployment, continuousintegration, devops