Exact gap from Continuous Integration to Continuous Delivery

Question

I have read some blog articles, papers and books about Continuous Integration and Continuous Delivery, but I still can't find a point where you could say this is where CI ends and CD starts.

I understand that CI is about integrating code changes by automatically building the new version of the software and testing it as soon as the change is committed. Now some sources say that the code is also being deployed into a production-like environment and automatically tested there as part of CI, while others say the staging and testing in that environment exactly what CD is all about.

So where can you draw the line between Continuous Integration and Continuous Delivery?

Answer 1

There are three activities that often get conflated or confused: Continuous Integration, Continuous Delivery, and Continuous Deployment.

Continuous Integration is integrating the work of individuals or teams continuously. You want to frequently merge code changes from multiple individuals or teams into a shared, common branch frequently. You then want to run automated tests to ensure that you can build the software and that it remains stable. Automated builds tests are key to Continuous Integration, as is frequently merging code from multiple people or teams. Although you have confidence in the software product, you don't have a deployable artifact yet - you may not have release build executables, installers, configurations, etc.

Continuous Delivery is the next step beyond Continuous Integration. The outcome of Continuous Delivery is a deployable product. Not only do you build and test, but you produce a production-ready build frequently. However, this build is not deployed to production. The decision to deploy a build is still a human decision. I have seen cases where the end result of Continuous Delivery is an automated deployment to a test, staging, pre-production, or similar non-production environment. Deployment may be a manual process or an automated one, but the outcome of Continuous Delivery is the input to your deployment process.

Continuous Deployment automates the deployment. Every successful build represents a deployment, often to a production environment. It requires Continuous Integration and Continuous Delivery to be successful.

---

A historical definition of Continuous Integration should be noted.

In Extreme Programming Explained: Embrace Change (2nd Edition), Kent Beck, the originator of XP and the Continuous Integration practice, described it as:

If the goal is to burn a CD, burn a CD. If the goal is to deploy a web site, deploy a web site, even if it is to a test environment. Continuous integration should be complete enough that the eventual first deployment of the system is no big deal.

Based on this definition, Continuous Integration extends through what we would today describe as Continuous Deployment. However, I don't think this aligns well with thinking about release, deployment, and delivery activities. It may have made sense for the first XP teams, but such a broad definition doesn't scale well. Having fine-grained terms and definitions allows for much better discussions of practices, tools, and capabilities.

Answer 2

• CI, you believe the code can be merged
• CD, you are confident the product can be deployed to production

They both work continuously, but the emphasis of CD is getting feedback from production like environment. That was back from the days when CI environments were different from production.

CD also makes sure that the processes to get the code deployed are tested for every merge. With CI, sometimes (most of the times?) people only want to deploy after some number of code merging. So, in CD the amount of code to be released depends on how often you want to deploy where in CI it depends on how often you want to create a build.