Continuous Integration

One important factor for the success of a software system is the speed with which the system adapts to changing requirements. Another success factor ist the speed with which a system can provide new functionality. Important for the quality of a system is also, to obtain feedback as early as possible about the stability and costumer value of the system.

XP addresses these and other questions using "continous integration", which is one of the 12 XP practices. This term describes the immediate and ongoing integration of completed tasks into the system. A completed task in general consists of both new unit tests and source code modifications.

The systems functionality is split up into small pieces (the tasks), which are added successively. Typically this is done in a way that several pairs of programmers work at different tasks at the same time. After a pair has finished a task, they will move to the integration machine in order to merge their source code modifications into the system. These changes which include the associated unit tests are then immediately available to all other pairs.

As this integration happens several times within a short time frame (several times a day), this leads to almost immediate integration of source code modifications. Each version of the system that is made available to the team passes all completed acceptance tests and all implemented unit tests successfully. In other words: A useable system is available immediately, the functionality of which is reproducable successfully tested.

Because of the very short timespans between integrations it is called continuous integration. This is in contrast to many of the traditional processes, where integration happens much less frequent. As a result it can become very difficult to get a system stable again.

Example: During development of a health care application integration was performed every two to three weeks. In general programmers could not remember all changes, which they applied to the system during these weeks. In case of a misbehavior of the system it was not possible to easily deduct the possible cause. Debugging the system was always time consuming and took up to 1 week. (For confidentiality reasons I left out the name of the company and of the product! The product is still sold. Source: Own observation)

Tips

• Integrate several times a day.
• Each completed task leads to the integration of both the integration of a source code modification and to the integration of the associated unit tests.
• A task will be integrated if and only if the source code and the associated unit tests are refactored. Only then the task is really complete.