In the News

Comparing Continuous Delivery vs. Continuous Deployment vs. Continuous Integration

Dev Leaders Compare Continuous Delivery vs. Continuous Deployment vs. Continuous Integration on Stackify, July 25, 2017

“In Agile software development the ultimate goal is to deploy working software to end-users (customers) as quickly as possible, often in 2-week increments…”

Software being developed does not add value until it’s deployed and being used. Also, when we deploy quickly we can see first hand how the software actually works. Agile places a premium on regularly (continuously) delivering software to the end-users.

In today’s environment, there is the concept of a “build pipeline” which represents the steps to move new code from development into production. The basic steps in the build pipeline are:

1. Develop code
2. Unit test (test the code locally to ensure it works as expected)
3. Integrate (the new code into the existing code base)
4. Acceptance test (test the entire system to ensure it meets the users expectations)
5. Deploy to production

The terms continuous delivery, integration, and deployment have multiple meanings, often based on the audience and context.

  • Continuous integration refers to the software development practice of regularly integrating new code into the existing code base. This can be accomplished with automated tools that include the integration and testing of the code base. Often the new code is integrated into the base daily with automated tests ensuring that the new code works as expected and does not adversely impact the rest of the system.
  • Continuous delivery is sometimes used to represent the end-to-end chain of regularly delivering code to production. Others state that continuous delivery means that you have the ability to deliver to production, but the actual deployment is a manual step.
  • In the context in which the deployment of code to production is manual, continuous deployment represents automation of that last step. Continuous deployment creates the opportunity to deploy new code into production several times a day.

These “continuous” processes, taken together, represent the end-to-end automation of the software build process where teams are “always ready” to deploy new changes. These processes have many benefits including lower risk, faster time to market, better quality, lower cost, and happier teams.

Conceptually, continuous integration, delivery, and deployment represent different segments of the build pipeline. To a large extent, the distinctions between these steps are not material. The goal is to build and deploy software as quickly as possible. The segmentation of the process is a byproduct of the different tool suites that address discrete steps along the build pipeline.