<p>Continuous delivery and continuous deployment (CD) are more or less the same thing*. Every time a change is considered 'good to go' (tested/verified) it should be release immediately. You can do this as many times a day as there is work completed.</p>

<p>Continuous integration (CI) only refers to merging code together often to ensure that feature branches don't veer too far away from your main 'master' branch, and also so that you know very quickly if there are any problems with the code from an integration perspective - i.e. Did you break any functionality while changing stuff.</p>

<p>As far as how they relate to each other, CI helps greatly to verify code so that it can be released quickly (CD). You can still achieve CD without CI (and vice versa), but you will find that often it makes life much easier to integrate your code early and often to find problems quicker, which in turn will allow you to fix said problems quicker, and finally deliver your features quicker!</p>

<p>*Edit: here is an article discussing the difference. <a href="https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff" rel="nofollow noreferrer">https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff</a>
Continuous delivery does not always mean actually deploying to production at all times, rather it means constant deployment into a production-like environment, with confidence that those changes could go to production at any time once the business is ready. In practice, most people conflate these terms. </p>

CC BY-SA 3.0
2017-03-12T07:08:47.087Z
merci! But as per your "more or less the same thing",  really? can you think of anything that illustrate any nuances?
Pierre.Vriens
CC BY-SA 3.0
2017-03-12T12:32:51.247Z
I've updated my post with a note about the differences, however I believe in normal conversation most people will use these terms interchangeably.
tayworm
CC BY-SA 3.0
2017-03-11T23:05:26.327Z
2017-03-12T12:31:40.683Z
2017-03-12T12:31:40.683Z
tayworm
<p>A certain version of a software product must first complete its integration stage before it can be delivered or deployed.</p>

<p>For <em>continous</em> delivery/deployment <em>continuous</em> integration is a must. Otherwise, if the integration completed events are too far apart to qualify for the "continuous" attribute then so are the possible deliveries/deployments (only a subset of the integrated versions typically qualify for deliveries/deployment).</p>

<p>Update: My answer only underlines the dependency (relationship) between CI and (both) CDs, the terminology is pretty well covered by THelper's answer.</p>

<p>The only comment I'd have to that is about the (overloaded) use of <code>deployment</code>. Deployments in non-production environments are a real thing. They can even happen often-enough - done, for example, as part of various testing stages during continuous delivery. But that doesn't make such deployments <code>continuous deployments</code>. Continuous deployments refers specifically to deployments in the production environment.</p>

CC BY-SA 3.0
2017-03-12T07:03:32.820Z
ok, that all helps, but maybe you can expand your answer with how you would describe delivery and deployment?
Pierre.Vriens
CC BY-SA 3.0
2017-03-11T23:58:25.663Z
2017-03-12T14:47:54.683Z
2017-03-12T14:47:54.683Z
Dan Cornilescu
<p>Basically, continuous integration is a part of both continuous delivery and continuous deployment, except that releases happen automatically. You can also think of continuous delivery as a logical next step of continuous integration and it works across all environments. 
Continuous integration also helps with artifact verification so it can be deployed quicker. Although it is not possible to have continuous deployment without continuous integration and it is so much easier to catch bugs with continuous integration. 
All of these “continuous things” are ultimately about removing unnecessary actions in development workflow. Most importantly, CI/CD are important from both technical and business perspective. Companies who fail to adopt these DevOps principles risk going the way of the dinosaurs. In today’s fast paced IT environment it is either <a href="https://squadex.com/insights/devops-or-die/" rel="nofollow noreferrer">DevOps or die.</a> </p>

CC BY-SA 3.0
2018-01-17T15:33:36.390Z
2018-01-17T15:33:36.390Z
DevOps Jedi
<p>CI (Continuous Integration): The most important reason for why we want to use CI is, that we want to avoid unnecessary complicated conflicts caused by delaying the merge of our work with the work of other team members and therefore also fix issues rather sooner than later, because the more we postpone discovery and resolution the more expensive and hard it is. We do that by frequently merging changes into
a common branch (for example the development branch). There is an automated component within Continuous Integration for the repeatable tasks, which is the pipelines that are running, which lint, test, build and possibly e2e test the software, but CI is not a fully automated process in regards to how we deploy to production. Most of the time this stems from the fact that the tests that the programmers write are
not trusted enough and do not give enough confidence for whatever reason.</p>
<p>CD (Continuous Delivery): Continuous Delivery is a fully automated process. It can only be a fully automated process if we fully trust the tests that we write. Therefore I’d argue you cannot have Continuous Delivery without E2E testing.The decision whether or not to release the new software version is made manually, but this is just a button click and a business decision not a technical decision, because we have
a production ready release after the pipeline passes. CI is a part of Continuous Delivery or in other words CI is a subset of Continuous Delivery. With Continuous Delivery everything is automated except the decision making process whether or not we deploy the release to production.</p>
<p>CD (Continuous Deployment): Same as Continuous Delivery, but we do not have that button, ie. everytime the pipeline on the release branch does pass, it gets pushed to production.</p>
<p>The aim of all three is the same, it is to avoid bugs and ship more frequently via improving collaborative workflows and automation.</p>

CC BY-SA 4.0
2023-06-26T23:06:48.717Z
2023-06-26T23:06:48.717Z
Ini
<p>Continuous delivery and continuous deployment both take continuous integration one step further, by adding a 'deployment to production' step to the process.
The difference between continuous delivery and deployment is that for delivery this step is done manually and for deployment is it automatic. </p>

<p><a href="https://i.sstatic.net/yOofB.png" rel="noreferrer"><img src="https://i.sstatic.net/yOofB.png" alt="Difference between Continuous Integration, Continuous Delivery and Continuous Deployment"></a></p>

<p><em>Difference between Continuous Integration, Continuous Delivery and Continuous Deployment. Picture copied from <a href="https://www.codeproject.com/articles/1078439/what-is-continuous-integration-and-why-do-you-need" rel="noreferrer">codeproject.com</a></em></p>

<p>Whether you do continuous delivery or continuous deployment is very much an implementation choice. If you do continuous deployment, changes in code will be deployed automatically after the acceptance tests are passed. This may or may not be desirable for your product. With continuous delivery, people can make a choice whether a particular code change  is deployed or not (and possibly where exactly it is deployed). </p>

<p>Since the difference between continuous delivery and deployment is small and many people are unaware of the exact difference, the two terms are sometimes used interchangeably.</p>

CC BY-SA 3.0
2017-03-12T10:42:43.273Z
Nice! But ... the solution (your answer) to a problem (my question), changes the problem ... [read more](http://devops.stackexchange.com/q/494/40) ...
Pierre.Vriens
CC BY-SA 3.0
2017-03-12T10:13:15.060Z
2017-03-12T10:13:15.060Z
THelper
<p>Here is a quote from the current content of <a href="/questions/tagged/continuous-integration" class="post-tag" title="show questions tagged &#39;continuous-integration&#39;" rel="tag">continuous-integration</a>:</p>

<blockquote>
  <p>... process of merging developer's working code copies to a shared codebase frequently to prevent or minimize integration problems.</p>
</blockquote>

<p>OK, I get that. But then there is also <a href="/questions/tagged/continuous-delivery" class="post-tag" title="show questions tagged &#39;continuous-delivery&#39;" rel="tag">continuous-delivery</a> and  <a href="/questions/tagged/continuous-deployment" class="post-tag" title="show questions tagged &#39;continuous-deployment&#39;" rel="tag">continuous-deployment</a>, and that's where I <em>continuously</em> get a bit lost:</p>

<ul>
<li>How does <em>continuous integration</em> relate to <em>continuous delivery</em> and/or <em>continuous deployment</em>, assuming that somewhere along the line(s) via <strong><em><code>integration</code></em></strong> you end up <strong><em><code>delivering</code></em></strong> in a target environment where everything will be <strong><em><code>deployed</code></em></strong>.</li>
<li>What's the difference between <em>continuous delivery</em> and <em>continuous deployment</em>?</li>
</ul>

<p>Back in the days, before DevOps was called DevOps, we used terminology which might possibly help to understand these new DevOps terms, such as:</p>

<ul>
<li><em>promote</em> to (or <em>demote</em> from) some pre-prod target, optionally combined with some type of regeneration process (compiles, binds, etc) to package all related components together in executable-like things. That's what should be similar/close to <em>continuous integration</em>, or not?</li>
<li><em>distribute</em> to some target environment, using something like FTP (if standard copies cannot bridge the gap), but do not yet activate it in the target. That's what should be similar/close to <em>continuous delivery</em>, or not?</li>
<li><em>install</em> (or <em>activate</em>) in some target environment, combined with things like binds, stop/start operations, etc. That's what should be similar/close to <em>continuous deployment</em>, or not?</li>
</ul>

CC BY-SA 3.0
2017-03-11T21:10:34.030Z
Too much tag markdown makes it hard to read.  That doesn't bring more context to the question so I think the Ords can be stressed by an _underline_ `_markdown_` to ease the reading
Tensibai
CC BY-SA 3.0
2017-03-11T21:22:49.877Z
I mean editing is a pain :) hint for answer http://blog.crisp.se/wp-content/uploads/2013/02/continuous-delivery-deployment-sm.jpg
Tensibai
CC BY-SA 3.0
2018-01-23T22:03:26.027Z
Related [StackOverflow post](https://stackoverflow.com/q/28608015/4495081)
Dan Cornilescu
CC BY-SA 3.0
2018-02-05T01:48:55.583Z
My related answer: https://softwareengineering.stackexchange.com/a/358551/3385
Nakilon
<continuous-integration><terminology><continuous-delivery><continuous-deployment>
How does continuous integration relate to continuous delivery / deployment?
Pierre.Vriens
# How does continuous integration relate to continuous delivery / deployment?

(Asked by: username_0 on 2017-03-11)

Here is a quote from the current content of [continuous-integration](/questions/tagged/continuous-integration "show questions tagged 'continuous-integration'"):

> ... process of merging developer's working code copies to a shared codebase frequently to prevent or minimize integration problems.

OK, I get that. But then there is also [continuous-delivery](/questions/tagged/continuous-delivery "show questions tagged 'continuous-delivery'") and [continuous-deployment](/questions/tagged/continuous-deployment "show questions tagged 'continuous-deployment'"), and that's where I *continuously* get a bit lost:

* How does *continuous integration* relate to *continuous delivery* and/or *continuous deployment*, assuming that somewhere along the line(s) via ***`integration`*** you end up ***`delivering`*** in a target environment where everything will be ***`deployed`***.
* What's the difference between *continuous delivery* and *continuous deployment*?

Back in the days, before DevOps was called DevOps, we used terminology which might possibly help to understand these new DevOps terms, such as:

* *promote* to (or *demote* from) some pre-prod target, optionally combined with some type of regeneration process (compiles, binds, etc) to package all related components together in executable-like things. That's what should be similar/close to *continuous integration*, or not?
* *distribute* to some target environment, using something like FTP (if standard copies cannot bridge the gap), but do not yet activate it in the target. That's what should be similar/close to *continuous delivery*, or not?
* *install* (or *activate*) in some target environment, combined with things like binds, stop/start operations, etc. That's what should be similar/close to *continuous deployment*, or not?

**Tags:** continuous-integration, terminology, continuous-delivery, continuous-deployment

> **Comments:**
> **username_1**: Too much tag markdown makes it hard to read.  That doesn't bring more context to the question so I think the Ords can be stressed by an _underline_ `_markdown_` to ease the reading  
> **username_1**: I mean editing is a pain :) hint for answer http://blog.crisp.se/wp-content/uploads/2013/02/continuous-delivery-deployment-sm.jpg  
> **username_2**: Related [StackOverflow post](https://stackoverflow.com/q/28608015/4495081)  
> **username_3**: My related answer: https://softwareengineering.stackexchange.com/a/358551/3385  

---

## 5 answers

### Answer by username_7 on 2017-03-12. Score: 27 | Accepted answer

Continuous delivery and continuous deployment both take continuous integration one step further, by adding a 'deployment to production' step to the process.
The difference between continuous delivery and deployment is that for delivery this step is done manually and for deployment is it automatic.

[![Difference between Continuous Integration, Continuous Delivery and Continuous Deployment](https://i.sstatic.net/yOofB.png)](https://i.sstatic.net/yOofB.png)

*Difference between Continuous Integration, Continuous Delivery and Continuous Deployment. Picture copied from [codeproject.com](https://www.codeproject.com/articles/1078439/what-is-continuous-integration-and-why-do-you-need)*

Whether you do continuous delivery or continuous deployment is very much an implementation choice. If you do continuous deployment, changes in code will be deployed automatically after the acceptance tests are passed. This may or may not be desirable for your product. With continuous delivery, people can make a choice whether a particular code change is deployed or not (and possibly where exactly it is deployed).

Since the difference between continuous delivery and deployment is small and many people are unaware of the exact difference, the two terms are sometimes used interchangeably.

> **Comments:**
> **username_0**: Nice! But ... the solution (your answer) to a problem (my question), changes the problem ... [read more](http://devops.stackexchange.com/q/494/40) ...  

---

### Answer by username_4 on 2017-03-11. Score: 4

Continuous delivery and continuous deployment (CD) are more or less the same thing\*. Every time a change is considered 'good to go' (tested/verified) it should be release immediately. You can do this as many times a day as there is work completed.

Continuous integration (CI) only refers to merging code together often to ensure that feature branches don't veer too far away from your main 'master' branch, and also so that you know very quickly if there are any problems with the code from an integration perspective - i.e. Did you break any functionality while changing stuff.

As far as how they relate to each other, CI helps greatly to verify code so that it can be released quickly (CD). You can still achieve CD without CI (and vice versa), but you will find that often it makes life much easier to integrate your code early and often to find problems quicker, which in turn will allow you to fix said problems quicker, and finally deliver your features quicker!

\*Edit: here is an article discussing the difference. <https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff>
Continuous delivery does not always mean actually deploying to production at all times, rather it means constant deployment into a production-like environment, with confidence that those changes could go to production at any time once the business is ready. In practice, most people conflate these terms.

> **Comments:**
> **username_0**: merci! But as per your "more or less the same thing",  really? can you think of anything that illustrate any nuances?  
> **username_4**: I've updated my post with a note about the differences, however I believe in normal conversation most people will use these terms interchangeably.  

---

### Answer by username_2 on 2017-03-11. Score: 3

A certain version of a software product must first complete its integration stage before it can be delivered or deployed.

For *continous* delivery/deployment *continuous* integration is a must. Otherwise, if the integration completed events are too far apart to qualify for the "continuous" attribute then so are the possible deliveries/deployments (only a subset of the integrated versions typically qualify for deliveries/deployment).

Update: My answer only underlines the dependency (relationship) between CI and (both) CDs, the terminology is pretty well covered by username_7's answer.

The only comment I'd have to that is about the (overloaded) use of `deployment`. Deployments in non-production environments are a real thing. They can even happen often-enough - done, for example, as part of various testing stages during continuous delivery. But that doesn't make such deployments `continuous deployments`. Continuous deployments refers specifically to deployments in the production environment.

> **Comments:**
> **username_0**: ok, that all helps, but maybe you can expand your answer with how you would describe delivery and deployment?  

---

### Answer by username_5 on 2018-01-17. Score: 1

Basically, continuous integration is a part of both continuous delivery and continuous deployment, except that releases happen automatically. You can also think of continuous delivery as a logical next step of continuous integration and it works across all environments.
Continuous integration also helps with artifact verification so it can be deployed quicker. Although it is not possible to have continuous deployment without continuous integration and it is so much easier to catch bugs with continuous integration.
All of these “continuous things” are ultimately about removing unnecessary actions in development workflow. Most importantly, CI/CD are important from both technical and business perspective. Companies who fail to adopt these DevOps principles risk going the way of the dinosaurs. In today’s fast paced IT environment it is either [DevOps or die.](https://squadex.com/insights/devops-or-die/)


---

### Answer by username_6 on 2023-06-26. Score: 0

CI (Continuous Integration): The most important reason for why we want to use CI is, that we want to avoid unnecessary complicated conflicts caused by delaying the merge of our work with the work of other team members and therefore also fix issues rather sooner than later, because the more we postpone discovery and resolution the more expensive and hard it is. We do that by frequently merging changes into
a common branch (for example the development branch). There is an automated component within Continuous Integration for the repeatable tasks, which is the pipelines that are running, which lint, test, build and possibly e2e test the software, but CI is not a fully automated process in regards to how we deploy to production. Most of the time this stems from the fact that the tests that the programmers write are
not trusted enough and do not give enough confidence for whatever reason.

CD (Continuous Delivery): Continuous Delivery is a fully automated process. It can only be a fully automated process if we fully trust the tests that we write. Therefore I’d argue you cannot have Continuous Delivery without E2E testing.The decision whether or not to release the new software version is made manually, but this is just a button click and a business decision not a technical decision, because we have
a production ready release after the pipeline passes. CI is a part of Continuous Delivery or in other words CI is a subset of Continuous Delivery. With Continuous Delivery everything is automated except the decision making process whether or not we deploy the release to production.

CD (Continuous Deployment): Same as Continuous Delivery, but we do not have that button, ie. everytime the pipeline on the release branch does pass, it gets pushed to production.

The aim of all three is the same, it is to avoid bugs and ship more frequently via improving collaborative workflows and automation.


---

