Continuous Integration
Continuous integration describes a process in software development that aims to combine the existing or newly created components of an application. This is intended to improve the quality of the software.
Continuous Integration (CI) is not about rebuilding the entire system, but about making statements about software quality through automated tests and software metrics.
General information
The larger software projects become, the more complex and difficult they are to handle. Since many developers are usually involved in the project, integration errors arise sooner or later which can sometimes be difficult to correct. Continuous Integration helps to solve this problem.
In principle, Continuous Integration is about counteracting the typical approach of creating software in long intervals approach and only shortly before delivery. Instead, it is created repeatedly in small cycles and constantly tested. This practice is designed to prevent errors from being detected until the day of release. In order to realize continuous integration, the source code must be managed with the help of a version control system; the developers in turn must permanently restore their work status to this system. The software is built at regular, short intervals after each commit or during time-consuming builds.
Then code analyses and tests are carried out in order to finally make the software available, for example with a stage system. The developers involved and possibly other parties involved are then informed about the build process and can view the analyses, logs and results. In this way, the developers do not receive reports of faulty commits through colleagues, but through permanent feedback from the Continuous Integration Server. Depending on requirements, project managers and customers always have up-to-date information about the development status or a current test system at their disposal.
Construction of a continuous integration system
A CI system consists of more components than just the CI server. The starting point is the project with which Continuous Integration is to be implemented, and the corresponding source code. The development team commits the changes it makes to the source code to the VCS. The server is first informed of the location of the project within the VCS. As a rule, a VCS-specific URL is used for this. Almost like a developer, the CI server now creates a local working copy of the project.
From now on, the CI server sends requests to the VCS at regular intervals to determine whether changes have occurred in the project concerned since the last time. If so, a new CI build is triggered in the CI server. The first step within such a CI build is basically that the CI server updates a local working copy of the VCS with an update. The next step is to "build" the project with these current files, which usually means compiling and running the automated tests.
Test execution and compilation are not performed by the CI server, but by a build tool such as Make or Maven. The prerequisite for this is the automation of the construction process carried out in advance by the development team and the use of build tool specific files, such as Maven's POMS or Makefiles.
Depending on how the build tool is called, the CI server classifies the entire CI build. It follows the following scheme:
1. Successful: No errors occurred either during compilation or during automated tests.
2. Warning: Both automated testing and compiling were successful. Nevertheless, small errors occurred, such as failed tests or warnings from the compiler.
3. Errors: The CI build is considered a failure because of numerous or critical errors. This can be the exceeding of a certain number of failed tests or a termination of the compiler.
By accessing the VCS, the CI server can determine who in the development team triggered the changes regarding the last CI build. The developers, in turn, are then informed of the build result by e-mail or other means. This enables them to find out promptly whether their changes have led to problems or errors.
Significance for development
Continuous integration has become a central tool in software development. The wisdom of the end, however, is not continuous integration, because the developments go further, other ideas and concepts enter the playing field again and again. These include, for example, continuous delivery, but also solutions with virtualization and clouds or Application Lifecycle Management (ALM).
Nevertheless, it can be said that Continuous Integration is often the right choice in practice and that this system is a respected tool for optimization in software development. Systems such as those mentioned above also play a role in software development, however, and it can be assumed that much will still be done in this area.