Continuous integration, continuous delivery, continuous deployment: just a nested doll

Hello to all!

We remind you that at the very beginning of September we published an interesting book by Eberhard Wolf “Continuous delivery. The practice of continuous updates "

In any booming industry, it is sometimes useful to define terms. For those who have not yet had time to get acquainted with the book of Wolf, we decided to translate a short article by Marko Anastasov, where the differences between Continuous Integration, Continuous Delivery and Continuous Deployment are clearly and clearly described. Welcome under the cut!
')



Continuous integration, continuous deployment and continuous delivery are like vectors whose direction is the same, and the module is different. The goal of all three techniques is the same: to increase the reliability of software development and releases, and also to speed up development and releases.

The main difference between the three approaches is the amount of automation at each of them. Beginners often confuse these phenomena, because they do not realize that they are not mutually exclusive, but enter each other like matryoshka dolls.

Core: continuous integration

Most developers, rolling into the topic, first of all get acquainted with continuous integration (CI), which is as follows: all changes made to the code are combined in the central repository (the operation is called "merging"). A merge occurs several times a day, and after each merge, an automatic assembly and testing is triggered in a specific project.

It happens that before building and testing the program is required to be compiled (it depends on the language in which it is written). Today, it is increasingly necessary to pack an application in a Docker container. Then, automated tests check specific code modules, UI operation, application performance, API reliability, and so on. All these steps are collectively referred to as “build”.

CI is a kind of safety net that allows developers to avoid a lot of problems before handing over the project. Therefore, programmers feel more confident in passing such code, but the work itself is unlikely to accelerate - perhaps the deployment will be performed manually, for a long time, and errors may also occur at this stage.

The maximum that developers can do in the first stage is to ensure that the automated test suite turns out to be exhaustive and stable enough so that you can safely start any assembly that has passed CI, first in running in, and then in production. So you can do without lengthy manual testing (QA).

Secondly, pay attention to the CI speed: I am convinced that developers should receive a CI result in a maximum of 10 minutes , otherwise productivity decreases due to loss of concentration and frequent switching between tasks. To speed up CI, it is convenient to parallelize tests on some powerful platform .

Transition to continuous delivery and deployment

Continuous Delivery (CD) is the practice of automating the entire software release process. Izhea is to perform CI, plus automatically prepare and release to production. It is desirable to achieve the following: anyone who has sufficient privileges to deploy a new release can perform a deployment at any time, and this can be done in a few clicks. The programmer, getting rid of almost all the manual work, is working more productively.

As a rule, in the process of continuous delivery, you need to perform at least one step manually: approve the deployment to production and start it. In complex systems with multiple dependencies, the continuous delivery pipeline may include additional steps, either manually or automatically.

Continuous deployment is “one level up” of continuous delivery. In this case, all changes made to the source code are automatically deployed to production, with no explicit sign of the developer. As a rule, the task of a developer is to check the request for inclusion (pull request) from a colleague and to inform the team about the results of all important events.

Continuous deployment requires that the team had a well-developed monitoring culture, everyone knew how to keep abreast of and quickly restore the system.

I have had to talk with many teams that practice continuous deployment. It turned out that developers really appreciate the ability to customize the deployment for different environments; It is equally important that everyone represents who, what and when deployed. Developers who practice CI and want to move to continuous deployment, to begin with, automate the deployment to the break-in environment, and continue to do the deployment in production manually - with one click.

Concept Borders

Since “continuous delivery” is a more fragile concept than “continuous integration” and “continuous deployment”, the first term is applicable in a wider context than at the level of an individual service or application — it can describe the operation of an entire system and even an organization.

For example, we can say that with full-fledged continuous integration, it should be possible in the event of an accident from scratch to create a full-fledged copy of the production environment - one command. Or agree that we will not be able to keep the development pace required in the team if we do not fit in with the deployment of a new microservice in about 5 minutes. This is where it is difficult to distinguish between continuous delivery and DevOps. Indeed, it is more logical to leave tasks such as automated provision of infrastructure (for this, the practice “infrastructure as a code”), logging on the scale of the entire product, and tracking of metrics are used in the DevOps category.

In addition, confusion sometimes arises, which means the abbreviation "CD" in the pair "CI / CD". There is no clear answer to this question, but in most cases this pair is understood as “continuous integration and continuous delivery”. This is logical, given that continuous deployment is a special case of continuous delivery, not applicable to every system.

Short summary and final thoughts

So:

• Continuous integration (CI): short-lived functional branches, the team merges them with the main development branch several times a day, the assembly and testing processes are fully automated, we have the result within 10 minutes; deployment is done manually.
• Continuous Delivery (CD): CI + automates the entire software release process. May consist of several stages. Deployment to production is done manually.
• Continuous deployment: CI + CD + fully automated production deployment.

In this post, I wanted to highlight the main characteristics of continuous integration, continuous delivery and continuous deployment, to describe the differences between these phenomena. Naturally, each of the three topics can be studied in much more detail - I recommend to follow the links listed in this article.