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?


2 Answers 2


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.

  • Let's say my software is automatically being built and then deployed to a testing environment so that some automated integration tests can be run against it to ensure that the cooperation with other services is working. Now is the process of deploying to that test environment a part of continuous integration (since the goal of the deployment is running the tests) or is it part of continuous delivery (since, like you said, deploying in a test environment is the end result of CD)?
    – Josef
    Dec 1, 2019 at 13:54
  • @josef98 It depends. Do people have access to this test environment? How long do these tests take to run? Continuous Integration needs rapid feedback to developers. My initial thinking is that I would be using Continuous Delivery to put the software in this test environment, where it undergoes more extensive testing.
    – Thomas Owens
    Dec 1, 2019 at 14:03
  • @josef98 I've been thinking a little more and I think it's important to define who you deliver to. So...who are you delivering to? An integration and test team? An independent quality assurance team? A customer or end user? If you define your process such that a test team is the customer of the development team (based on your process definition), you could refer to continuous deployment to refer to deploying to their environment. They would gate a deployment to end users, perhaps.
    – Thomas Owens
    Dec 1, 2019 at 18:27
  • 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.