Reference: how the Continuous Integration process works

Today we will look at the history of the term, discuss the difficulties of implementing CI, and present several popular tools that will help you work with it.

Reference: how the Continuous Integration process works
/flickr/ Altug Karakoc / CC BY / Photo modified

Term

Continuous Integration is an approach to application development that involves frequent project builds and code testing.

The goal is to make the integration process predictable and to detect potential bugs and errors at an early stage so that there is more time to fix them.

The term Continuous Integration first appeared in 1991. It was introduced by the creator of the UML language Gradi Butch (Grady Booch). The engineer introduced the concept of CI as part of his own development practice βˆ’ Booch method. It meant incremental refinement of the architecture when designing object-oriented systems. Gradi did not describe any requirements for continuous integration. But later in his bookObject Oriented Analysis and Design with Applicationshe said that the purpose of the technique is to speed up the release of "internal releases".

History

In 1996, CI was adopted by the creators of the methodology extreme programming (XP) - Kent Beck (Kent Beck) and Ron Jeffries (Ron Jeffries). Continuous Integration has become one of the twelve key principles of their approach. The founders of XP clarified the requirements for the CI methodology and noted the need to build the project several times a day.

In the early 2000s, the methodology of continuous integration began to be promoted by one of the founders of the Agile Alliance Martin Fowler (Martin Fowler). His experiments with CI led to the emergence of the first software tool in this area - CruiseControl. The utility was created by Martin's colleague Matthew Foemmel.

The build cycle in the tool is implemented as a daemon that periodically checks the version control system for changes in the codebase. The solution can be downloaded today - it spreads under a BSD-like license.

With the advent of software for CI, more and more companies began to adopt the practice. According to Forrester research [page 5 of the report], in 2009, 86% of fifty technology companies surveyed used or implemented CI methods.

Today, the practice of Continuous Integration is used by organizations from a wide variety of industries. In 2018, a major cloud provider conducted a survey among IT specialists of companies from the service, education and finance sectors. Of the six thousand respondents, 58% answered that they use the tools and principles of CI in their work.

How it works

The basis of continuous integration is made up of two tools - a version control system and a CI server. The latter can be either a physical device or a virtual machine in a cloud environment. Developers upload new code one or more times a day. The CI server automatically copies it with all dependencies and builds it. After - runs integration and unit tests. If the tests pass successfully, then the CI system deploys the code.

The general scheme of the process can be represented as follows:

Reference: how the Continuous Integration process works

The CI methodology imposes a number of requirements on developers:

  • Fix problems immediately. This principle came to CI from Extreme Programming. Fixing bugs is the top priority for developers.
  • Automate processes. Developers and managers must constantly look for "bottlenecks" in the integration process and eliminate them. For example, often the "bottleneck" of integration turns testing.
  • Build as often as possible. Once a day to keep the team in sync.

Difficulties of implementation

The first problem is high operating costs. Even if a company uses open CI tools (which we'll talk about later), it still has to spend money on maintaining the infrastructure. However, the cloud may be the solution.

They simplify the assembly of multi-scale computer configurations. Company plus pay only for the resources used, which helps to save on infrastructure.

Polls [p.14 Articles], continuous integration increases the burden on company employees (at least at first). They have to learn new tools, and colleagues do not always help with learning. Therefore, you have to deal with new frameworks and services on the go.

The third difficulty is problems with automation. It is faced by organizations with a large amount of legacy code that is not covered by automated tests. This leads to the fact that the code is simply rewritten before the full implementation of CI.

Reference: how the Continuous Integration process works
/flickr/ tailr / CC BY-SA

Who uses

IT giants were among the first to appreciate the advantages of the technique. Google uses continuous integration since the mid-2000s. CI was introduced to solve the problem with delays in the search engine. Continuous integration helped to quickly detect and fix problems. Now CI is used by all departments of the IT giant.

Continuous integration also helps small companies, and financial and medical organizations also use CI tools. For example, at Morningstar, continuous integration services helped patch vulnerabilities 70% faster. And the Philips Healthcare medical platform was able to double the speed of testing updates.

Tools

Here are some popular CI tools:

  • Jenkins is one of the most popular CI systems. It supports more than a thousand plugins for integration with various VCS, cloud platforms and other services. We also use Jenkins in 1cloud: a tool part of our DevOps system. It regularly checks out the Git branch intended for testing.
  • buildbot - python framework for writing your own continuous integration processes. The initial setup of the tool is quite complicated, but this is offset by the wide range of customization options. Among the advantages of the framework, users highlight its low resource consumption.
  • Concourse CI is a server from Pivotal that uses Docker containers. Concourse CI integrates with any version control tools and systems. The developers note that the system is suitable for work in companies of any size.
  • Gitlab CI is a tool built into the GitLab version control system. The service runs in the cloud and uses YAML files for configuration. Like Concourse, Gitlab CI applies Docker containers that help isolate different processes from each other.
  • codeship is a cloud CI server that works with GitHub, GitLab and BitBucket. The platform does not require a long initial setup - standard pre-installed CI processes are available in Codeship. For small (up to 100 builds per month) and open source projects, Codeship is available for free.

Materials from our corporate blog:

Source: habr.com

Add a comment