CruiseControl
CruiseControl is a toolkit available as open source for the so-called continuous integration (Continuous Integration) of software systems in the context of a build process, which can be started time-dependent or event-dependent. CruiseControl is platform independent, originally implemented in Java - but there is also an implementation in Ruby a . NET. Therefore, an adequate runtime environment must be provided for execution in each case. CruiseControl is available according to the BSD license conditions under the link below - currently in version 2.8.3 - and is certified by OSI. Access to the artifacts of the test run is possible via emails as well as RSS feeds, among others. A tool comparable to CruiseControl is Hudson.
The terms of the BSD license state that software may be used freely - i.e. copying, modifying and distributing the software is allowed - as long as the copyright marking of the original software is preserved.
Continuous integration
Continuous integration is the process of rebuilding and testing software, especially on a regular and complete basis. Depending on the scope of the project, the size of the team or the demands placed on the system, an environment of this kind can become arbitrarily complex. In any case, a central version management(Subversion, CVS, etc.) is needed as a basis, from which the software is then "taken" and the "builds" are created automatically with the help of special scripts. The translation into executable units takes place with the continuous integration usually several times daily - ideally with each accepted change (Commit). It is also common to create so-called nightly builds, a nightly build process followed by a deployment (installation) process and automatic start of execution. If one of these processes ends with an error, this is referred to as a broken build. The figure illustrates the basic flow of a build process.
In connection with CruiseControl, one also speaks of an integration server. This is used for automated integration by subjecting checked-in code to a complete build and test cycle on a separately set up system - CruiseControl is then the software for operating this server.
The core of CruiseControl
The core of CruiseControl basically consists of the following parts: the build loop, the build results JSP and the dashboard.
The build loop generates a process in the background of the integration server, whose configuration is done via an XML file. The integration server periodically checks whether changes have been made in the central source code repository. If this is the case, the following steps are processed:
- by interacting with the version management system, the latest versions of the source code are made available,
- then execution of all necessary compile, link and package processes,
- the generation of all previously defined test runs and finally
- informing all involved versions about the artifacts (results) of the last build.
In doing so, CruiseControl supports access to the artifacts in different ways. All developers who have provided code for the current build can be notified by e-mail or RSS feed. If errors have occurred, the corresponding developer is also notified in order to correct them by a date to be agreed upon and then check in the corrected source code again into the version management or check out the faulty file in general.
In addition, a log file is created after each build loop, which is used by the Build Results JSP as the basis for a history of the artifacts.
A clear form of visualization of the artifacts of all build and test cycles is offered by the CruiseControl Dashboard. Both currently running processes and the results of the compilation are displayed. The graph includes the errors of the compilation, the results of the tests and details regarding the files that have changed since the past build process.
With the use of a separate integration server, a consistent repository of the source code can be ensured at all times. This also makes it possible to determine at an early stage whether all files are available for a full build process. A sensible distribution of resources with regard to complex test cycles can also be represented in this way.