What do Continuous Integration (CI) and Continuous Delivery (CD) Mean

When talking about software development, the terms Continuous Integration (CI) and Continuous Delivery (CD) are often mentioned. But what do they really mean? In this article, I will explain the meaning and meaning behind these and related terms, such as Continuous Testing and Continuous Deployment.

Overview

The assembly line in the factory produces consumer goods from raw materials in a fast, automated, and repeatable manner. Similarly, software delivery pipelines generate release versions from source code in a fast, automated, and repeatable manner. The overall design of how to accomplish this work is called "Continuous Delivery" (CD). The process of starting the assembly line is called "Continuous Integration" (CI). The process of ensuring quality is called "continuous testing", and the process of providing the final product to users is called "continuous deployment." Some experts make it all simple, smooth, and efficient. These people are called DevOps practitioners.

What does "continuous" mean?

"Continuous" is used to describe practices that follow many of the different processes I mention here. This does not mean "always running", but "ready to run". In the field of software development, it also includes several core concepts/best practices. these are:

1. Frequent release: The goal behind continuous practice is to be able to deliver high-quality software frequently. The delivery frequency here is variable and can be defined by the development team or company. For some products, one quarter, one month, one week or one day delivery may be frequent enough. For others, it may be possible to deliver multiple times a day. The so-called continuous also has an "occasional, on-demand" aspect. The ultimate goal is the same: to provide end users with high-quality software updates in a repeatable and reliable process. Usually, this can be done with little or no user interaction or knowledge (think device updates).

2. Automated process: The key to achieving this frequency is to use an automated process to handle all aspects of software production. This includes building, testing, analysis, version control, and in some cases deployment.

3. Repeatable: If the automated process we use always has the same behavior given the same input, the process should be repeatable. In other words, if we take a certain historical version of the code as input, we should get the same deliverable output. This also assumes that we have external dependencies of the same version (that is, we do not create other deliverables used by this version of the code). Ideally, this also means that the processes in the pipeline can be versioned and rebuilt (see the DevOps discussion later).

4. Fast iteration: "Fast" is a relative term here, but regardless of the frequency of software updates/releases, the expected continuous process will convert source code into deliverables in an efficient manner. Automation is responsible for most of the work, but the process of automation may still be slow. For example, for a product that needs to release candidate version updates multiple times a day, it may be too slow for a round of integrated testing to take more than half a day.

What is Continuous Integration?

Developers practicing continuous integration merge their changes back to the main branch as often as possible. The developer's changes are validated by creating a build and running automated tests against the build. By doing so, you avoid integration challenges that can happen when waiting for release day to merge changes into the release branch.

Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

What is Continuous Delivery?

Continuous delivery is an extension of continuous integration since it automatically deploys all code changes to a testing and/or production environment after the build stage.

This means that on top of automated testing, you have an automated release process and you can deploy your application any time by clicking a button.

In theory, with continuous delivery, you can decide to release daily, weekly, fortnightly, or whatever suits your business requirements. However, if you truly want to get the benefits of continuous delivery, you should deploy to production as early as possible to make sure that you release small batches that are easy to troubleshoot in case of a problem.

What is Continuous Deployment?

Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There's no human intervention, and only a failed test will prevent a new change to be deployed to production.

Continuous deployment is an excellent way to accelerate the feedback loop with your customers and take pressure off the team as there isn't a Release Day anymore. Developers can focus on building software, and they see their work go live minutes after they've finished working on it.

What's the difference between CI and CD (and the other CD)?

The acronym CI/CD has a few different meanings. The "CI" in CI/CD always refers to continuous integration, which is an automation process for developers. Successful CI means new code changes to an app are regularly built, tested, and merged to a shared repository. It’s a solution to the problem of having too many branches of an app in development at once that might conflict with each other.

The "CD" in CI/CD refers to continuous delivery and/or continuous deployment, which are related concepts that sometimes get used interchangeably. Both are about automating further stages of the pipeline, but they’re sometimes used separately to illustrate just how much automation is happening.

Continuous delivery usually means a developer’s changes to an application are automatically bug tested and uploaded to a repository (like GitHub or a container registry), where they can then be deployed to a live production environment by the operations team. It’s an answer to the problem of poor visibility and communication between dev and business teams. To that end, the purpose of continuous delivery is to ensure that it takes minimal effort to deploy new code.

Continuous deployment (the other possible "CD") can refer to automatically releasing a developer’s changes from the repository to production, where it is usable by customers. It addresses the problem of overloading operations teams with manual processes that slow down app delivery. It builds on the benefits of continuous delivery by automating the next stage in the pipeline.

How the practices relate to each other

To put it simply continuous integration is part of both continuous delivery and continuous deployment. And continuous deployment is like continuous delivery, except that releases happen automatically.