CI/CD

What is CI/CD

In software development, CI/CD or CICD is a combination of continuous integration (CI) and continuous deployment (CD) of software during the development process.

CI/CD unites development , deployment and the team, speeding up the process of building, testing and deploying the application.

At the moment DevOps programmers strive to apply CI/CD to virtually all tasks

Continuous Integration

Continuous integration is a software development practice that consists in the constant merging of working copies into the common main branch of development (up to several times a day) and in performing frequent automated builds of the project in order to detect potential defects and solve integration problems as early as possible.

In an ordinary project, where developers work on different parts of the system independently, the integration stage is the final one.

It can unpredictably delay the completion of the work. The transition to continuous integration makes it possible to reduce the labor intensity of integration and make it more predictable through the earliest possible detection and elimination of errors and contradictions, but the main advantage is the reduction of the cost of fixing a defect, through its early detection.

It was first conceptualized and proposed by Grady Booch in 1991. It is one of the main elements of the extreme programming practice.

Organizing CI

To apply the practice, a number of basic requirements for the development project must be met.

In particular, the source code and everything necessary for building and testing the project must be stored in the repository of the version control system, and the operations of copying from the repository, building and testing the whole project must be automated and easily invoked from external programs.

To organize the continuous integration process, a service is started on a dedicated server, whose tasks include:

• obtaining the source code from the repository
• building the project
• running the tests
• deploying the finished project
• sending reports

A local build can be carried out on an external request, on a schedule, upon the fact of a repository update and by other criteria.

Scheduled builds (Eng. daily build — a daily build), as a rule, are carried out outside working hours, at night (Eng. nightly build), and are planned so that by the start of the next working day the test results are ready.

To distinguish them, a build numbering system is additionally introduced — usually, each build is numbered with a natural number, which increases with each new build.

The source texts and other source data, when taken from the repository (storage) of the version control system, are marked with the build number.

Thanks to this, exactly the same build can be reproduced exactly in the future — it is enough to take the source data at the required label and start the process again.

This makes it possible to re-release even very old versions of a program with minor fixes.

Advantages and disadvantages

The advantages of continuous integration include the following points:

• integration problems are detected and fixed quickly, which turns out to be cheaper
• an immediate run of unit tests for fresh changes
• the constant availability of the current stable version together with the build products — for testing, demonstration, etc.
• the immediate effect of incomplete or non-working code accustoms developers to working in an iterative mode with a shorter cycle.

At the same time, the practice is not without disadvantages, in particular:

• significant costs for maintaining the operation of continuous integration
• the need for additional computing resources for the needs of continuous integration

In addition, the immediate effect of incomplete or non-working code weans developers from making periodic backup inclusions of code into the repository, but in the case of using a version control system for the source code with branching support, this problem can be solved by creating a separate “branch” (Eng. branch) of the project for making large changes (code whose development up to a workable version will take several days, but more frequent saving of the result to the repository is desirable).

After the completion of development and individual testing of such a branch, it can be merged (merge) with the main code or the “trunk” (trunk) of the project.

Continuous delivery

Continuous delivery — is an approach to software development in which software is produced in short iterations, guaranteeing that the software is stable and can be put into operation at any time, while its transfer happens manually.

The goal is to build, test and release software with greater speed and frequency.

The approach makes it possible to reduce the cost, time and risks of making changes through more frequent small updates to the production application.

CD differs from continuous deployment, in which the software is also produced in short cycles through automatic deployment, as opposed to manual.