Continuous integration boosts efficiency by enabling automation as well as early and regular testing and has become the preferred approach for large projects. Now organisations are working to achieve ongoing improvements in this proven process. At the same time, increasing numbers of small teams are also focusing on continuous integration. Nowadays, anyone involved in large, complex software development projects using the latest methodology can hardly fathom the enormous challenge that integration once posed: Numerous build scripts had to be executed in sequence, involving the adaptation of very many configuration files and comparison of different timestamps and versions. This phase was very error-prone and it was difficult to see through to the end. It was about ten years ago that the first development teams introduced a different approach that is now known as continuous integration (CI). Publications by Martin Fowler and Kent Beck helped to popularise this concept by adopting continuous integration into the model of extreme programming. Continuous integration is based on two pillars. First of all, work results produced by the developers are integrated very frequently, meaning at least once per day. Second, continuous integration is characterised by the use of automation. A build is made automatically each time that work is checked into the version control system. Automated unit tests are also performed. Results are available quickly, and ideally within minutes. Moreover, deployment in different test environments and reporting are also commonly automated. The individual substeps are introduced successively.
Fig. 1: Components in a CI environment
Continuous integration – successful introduction in a small team
A service company is interested in improving the efficiency of a small software development team. An external consultant is hired for this purpose. He has experience with continuous integration and proposes introducing this approach in the team. The project supervisor in charge agrees. The fact that the costs and risk of the introduction process are very limited plays an important role in the decision. A simple workstation is adequate for use as the build server. Respected open-source products are available for automatic builds and tests. This cuts costs and puts the dependency on a new tool required for the introduction of continuous integration into the proper perspective. Since CI represents a process optimisation, it could also be reversed, even during the development phase of a product, with no problems. However, practical experience has shown that this is not desirable anyway. The introduction is then handled in a step-by-step manner. First, more intensive cooperation is encouraged between the developers in the team. The external consultant leads the way with a good example for the desired cooperation. The main focus here is on the goal of a functional build. Work on new functionalities begins only once this goal is reached. The build server serves as the reference point. This makes any claims that “it runs on my PC” irrelevant and prevents situations where some team members are delayed because other colleagues checked in something that cannot be built. During an initial technical stage, automatic builds are introduced. This is followed in stages by automatic tests, automatic deployment and reporting. Nowadays, continuous integration is so well established in the development process that the developers can’t imagine working without it. It has helped to eliminate monotonous, repetitive activities. Moreover, the developers can be certain they haven’t forgotten anything and that the code they check in can be built. At the same time, the integration phase at the end of the project with its many uncertainties has been eliminated. Also important: the better cooperation has improved the mood within the team and thus the level of motivation. Passing the blame is now a thing of the past – along with claims that “the code runs on my machine”.
Fig. 2: Sample process with CI
Continuous integration - economical and efficient thanks to automation
The developers are definitely not alone in benefiting from continuous integration. The method is a proven means to boost efficiency and thus reduce time to market – without adding additional resources. This is achieved, on the one hand, through automation. Repetitive, time-consuming tasks are eliminated while the number of errors upon integration is simultaneously reduced. On the other hand, errors in the code and configuration are detected at an early stage – and before the integration phase at the end of the project. Early detection translates into correction with less effort. For larger systems that require several hours to compile and test, the night hours can be exploited for integration and automatic unit tests. When the employees arrive in the morning, a report is available documenting errors in the build and functionality. The product quality is improved at the same time. This is not due solely to automation and the early detection of errors – the reporting facility also increases the transparency and thus provides support for project management. Moreover, the management team is relieved to know that a functional build exists at all times during development. Of course, an initial effort is required to enjoy these advantages. This investment is clearly worth the significant benefits it delivers, but it is important to not underestimate what is required. At least one employee must take charge of continuous integration. This person is responsible for evaluating, setting up and configuring the tools and creating the scripts. Moreover, the scripts must be adapted for each new project. The cost/benefit ratio is more favourable in large projects, and it was in such projects that continuous integration first began to gain traction. Here, it even pays off to strive for ongoing optimisation of the methodology.