Continuous integration

from Wikipedia, the free encyclopedia

Continuous integration (also continuous or permanent integration ; English continuous integration ( CI ) ) is a term from software development that describes the process of the continuous assembly of components into an application . The goal of continuous integration is to increase software quality. Typical actions are the translation and linking of the application parts, but in principle any other operations for generating derived information can also be carried out. Usually, not only is the entire system built from scratch, but automated tests are also carried out and software metrics for measuring software quality are created. The entire process is triggered automatically by checking into the version management .

A precursor of continuous integration is the nightly build (nightly build process ). In practice, one also encounters continuous integration, paired with a nightly build in order to combine the advantages of both systems. In the DevOps method , this automation is also called a pipeline, as the individual steps are processed sequentially. The pipeline makes it possible to increase the development speed, because after a few minutes the developer receives feedback as to whether the quality requirements have been met or not.

Continuous Delivery ( CD ) represents a further development of the continuous integration . A new version of the software is delivered at certain time intervals or when a certain quality metric is reached.

Principles

At least since the concept of permanent integration was made popular by Kent Beck in the context of Extreme Programming , the term continuous integration has been known, but for a successful introduction some principles (see "Continuous Integration" by Martin Fowler ) must be followed :

Common code base
In order to be able to integrate meaningfully within a work group, a version management system must exist in which all developers can continuously integrate their changes.
Automated translation
Every integration must go through uniformly defined tests such as static code reviews before the changes are integrated. An automated translation is necessary for this.
In order to make test results independent of the working environment, the use of separate test environments is recommended. This means that specific processes can be implemented on these computers in order to minimize the test run time.
Continuous test development
Every change should be developed at the same time as possible with an associated test (for example by means of test-driven development ). With the help of control flow-oriented test procedures (analysis of code coverage, English: "Code Coverage Analysis") this procedure can be documented and controlled.
Frequent integration
Every developer should integrate his changes into the common code base as often as possible. Short integration intervals reduce the risk of failing integrations and at the same time ensure that the developers work in the common code base (data backup).
Integration into the main branch
Every developer should integrate his changes into the main branch of the product, where a build and test cycle is then automatically started. This build is called the continuous integration build.
Short test cycles
The test cycle prior to integration should be kept short to encourage frequent integrations. With increasing quality requirements for the individual integrations, the runtime for executing the test cycles also increases. The amount of tests performed prior to integration must be carefully weighed; less important tests are then only performed after integration.
Mirrored production environment
The changes should be tested in an image of the real production environment.
Easy access
Even non-developers need easy access to the results of software development. These do not necessarily have to be sources, but can be, for example, the product for testers played in the test system, the quality figures for those responsible for quality, the documentation or a fully packaged image for the release manager .
Automated reporting
The results of the integrations must be easily accessible. Both developers and others involved must be able to easily get information about when the last successful integration was carried out, what changes have been made since the last delivery and what quality the version is.
Automated distribution
Each version should be easily transferable to a production environment (or an image of the same). For this, the software distribution should be automated.

Continuous integration can be carried out on any computer with access to the source code. In particular, it is possible to carry out the integration simultaneously on different systems (e.g. different operating systems).

advantages

  • Integration problems are constantly discovered and resolved (fixed) - not just before a milestone .
  • Early warnings of mismatching items.
  • Immediate unit tests detect errors promptly. In the ideal case, for example, you can immediately notice when a commit introduces an error.
  • Constant availability of an operational stand for demo, test or sales purposes.
  • The immediate reaction of the system to the check-in of faulty or incomplete code "educates" the developers in a positive sense to be more responsible and to use shorter check-in intervals. The longer you wait with the integration, the greater the merge effort.

software

Exemplary tools for continuous integration:

Web links

Individual evidence

  1. ↑ FOWLER, Martin. Continuous Integration (English)