Differences and Relationships among Continuous Integration, Continuous Deployment, and Continuous Delivery

What is the difference and relationship among “Continuous Integration”, “Continuous Deployment”, and “Continuous Delivery”?

I am often asked this question by friends and colleagues.

Some people illustrate a progressive relationship with a diagram (see image below), but I do not share that view.

Below is my own understanding of these concepts.

What does “continuous” mean? It refers to “without gaps, continuously”. In software delivery, no one has truly achieved uninterrupted continuity; companies differ only in the length of the intervals between deployments (minutes, hours, weeks, or months).

Integration (Integration) : combining different parts of an object to make it whole and functional.

Software Integration usually means the supplier combines various modules or services of a software product into a single system to verify that the software can provide the expected services.

Deployment (Deployment) : placing an object into an environment so that it is ready to provide a capability, similar to “troop deployment”.

Software Deployment is the operation of putting integrated software into a runtime environment so it can start and provide its functions. This typically occurs in a controlled environment (e.g., server‑side). When deployment happens in an uncontrolled environment (e.g., a mobile client) after the user obtains a copy, the term Delivery is more appropriate.

Delivery (Delivery) : handing an object over to another party to obtain benefit or complete a transaction.

Software Delivery means the supplier hands over software that meets a fixed quality standard to the receiver, thereby generating business value and expecting the receiver to pay for that value.

The differences lie in their nature and scope (see diagram).

Software integration is a development activity that makes software runnable in a supplier’s environment, usually occurring internally.

Software deployment is a technical operation that may happen in either the supplier’s or the receiver’s environment.

Software delivery is a business‑value transaction that provides value to the receiver and obtains corresponding benefits, which are not limited to direct monetary returns.

Wikipedia’s definitions of CI, CD, and CDel are shown below.

Continuous Integration is a software development practice where team members frequently integrate their code—typically at least once per day per developer—so that the codebase is built and tested automatically each time, allowing early detection of integration problems.

Martin Fowler introduced this definition in 2004, specifying both the content and frequency of integration.

Many teams today claim to practice “continuous integration” without fully meeting this definition, but the exact terminology is less important than the outcomes.

Continuous Deployment means that every change is automatically deployed to the production environment.

Continuous Delivery means the team ensures every change is deployable to production (i.e., meets delivery quality), but may hold back release for business reasons.

In my view, the two differ in two main aspects:

1. Business value : Continuous Deployment is a technical operation; the code may be deployed but not yet generate business value. Continuous Delivery always involves a business‑value transaction, aiming to obtain revenue or other benefits.

2. Location of operation : Deployment usually refers to server‑side technical actions, whereas Delivery also includes distributing software copies to end users.

When both deployment and delivery are considered as providing business value, the distinction can blur, as seen in companies like IMVU and Facebook.

IMVU – 50 engineers, ~50 deployments per day

In IMVU’s simple pipeline, each code commit triggers a 15‑minute automated verification; if no issues are found, the change is automatically deployed to production (see image). The system also includes an “immune system” that monitors production and rolls back the latest deployment if a problem is detected.

Buildbot, similar to Jenkins, is used for the automated verification.

Facebook – 800+ engineers

Facebook’s front‑end product code is pushed twice a day on average. With over 800 engineers using trunk‑based development, each push contains many developers’ changes. Not every push immediately affects users; feature‑flag platforms like Gatekeeper control which users see which functionality.

Because of the large team and branch‑release strategy, each push typically delivers either bug fixes or new user experiences, thereby providing business value.