Continuous Integration

integrate code several times a day using automated processes
Contact us
Programmers and developers know all about “integration hell”. It’s a term that refers to the difficulty of merging several streams of product development at the end of a project. Leaving things late in the day can lead to all sorts of code clashes and going through the work with a fine-tooth comb to get the code up to scratch can be a much bigger job than the original development. One alternative to this approach is continuous integration.

Continuous Integration

A High-Level Overview
The main principle of continuous integration is that each developer workspace is merged with the main development line multiple times a day. Continuous integration is in essence an offshoot of “eXtreme programming”. In its first iteration the idea was that by using automated testing you could ensure that each development stream was progressing without causing issues to the main body of code. Later iterations incorporated the use of build servers which pick up the latest build and then re-run the unit tests.

Continuous Integration

The Principles
In order to use continuous integration you need to start with a code repository (an essential that also allows for strong levels of version control). All objects and artifacts should be held within the repository and each build should be able to be extracted from the repository without the use of additional code or dependencies.

Then continuous integration requires that the build should be automated (and there are plenty of easily available software tools to do just that) and that the build should be self-testing. That means the tests should execute without the need for a manual start from the development team. It’s important that the build is created quickly so that results from testing can be fed back into the development approach rapidly.

It’s recommended that the build is a mirror of your production environment to ensure that your testing environment is a mirror of real-life. Developing testing instances that don’t conform to this principle make continuous integration a waste of time – as there’s a strong chance that the final product will still need to be altered for production.

It’s essential that all developers are working on the same baseline instance each day and that the baseline is committed each day. This reduces the chance of introducing additional creeping errors into the code and allows developers to deal with conflicting code as it arrives. Continuous integration without this simply isn’t possible.

Test results for continuous integration need to be shared with the whole development team. It’s important that there are no arduous steps between programmers and the results – otherwise your development team can’t alter their approach rapidly enough.

Continuous Integration

The Benefits

There are many benefits to using the continuous integration approach to development: