How does continuous integration relate to continuous delivery / deployment?

Question

Here is a quote from the current content of 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 and 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?

Answer 1

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. Picture copied from codeproject.com

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.

Answer 2

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.

Answer 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 THelper'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.

Answer 4

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.

Answer 5

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.