Continuous Integration vs Continuous Delivery vs Continuous Deployment

^{Originally posted on LinkedIn, updated.}

Over my career I have worked with a number of different software product companies and in my role I have the benefit of seeing different practices across different teams and clients. As a former, but very rusty, software engineer (Java, Objective C, AIX… vintage 1997), I am enjoying brushing up on my knowledge of software engineering practices, platforms and Agile practices. I am going to take a topic at a time and try to distill what I have learned, as much for myself as for anyone who may want to get a high level understanding of these topics.

Continuous Integration and Continuous Delivery/Deployment has been coming up with many of our clients as a best practice; certainly an acknowledged best practice, but one that we observe different teams are at differing levels of maturity on.

After reading a number of articles on CI/CD, I have found these three images which have best explained to me the nature and nuances of the practice.

First, this image created by Atlassian and on their blog (click through on the image to the original article) is a very simple but powerful depiction of what is meant by all these different terms.

What is Continuous Integration?

Continuous Integration is the practice of merging code that is being developed into the main branch from individual developers’ branches easily and quickly, so that any bugs can be caught early and often. As the code is checked in, it is verified by an automatic build. 

What is Continuous Delivery/Deployment?

Continuous Delivery then is the practice of taking that built (compiled, runnable) code and making it available to be deployed either manually or automatically (Continuous Deployment) to product or test environments.

What does this mean for Business Value?

The holy grail of continuous deployment by Netflix may not be the immediate objective of your software development team, but both your engineering leaders and shareholders are probably interested in achieving similar results over time. Essentially, what a well structured process and practice of continuous integration and delivery/deployment provides a product team is speed to market and productivity gains.

If your programmers don’t have to wait to know whether their code worked, and if your scrum teams can eliminate manual, tedious repetitive tasks, your product will be built better and faster so you can get customer feedback more often and earlier in the product maturation cycle. And you will get product shipped!