Reification of the integration Process in an Artifact

The dependency diagram in [Beck2000, p. 70], focuses on continuous integration, which is shown to be directly related to collective ownership, coding standards, testing, refactoring, pair programming, and short releases. If a team has problems with continuous integration, this is likely to cause problems with other XP techniques. But if continuous integration works well, it should support many other XP techniques.

When we started using XP techniques, continuous integration was one of the first we adopted. We tried to establish the technique as suggested in [Beck2000]. We used one physical integration machine for the whole team (about eight developers), which always keeps a consistent and running version of the system under development. However, this did not work as expected. We achieved only a few integrations per week, and the team's motivation was adversely affected.

The reason for the failure to establish continuous integration was easily found: Each integration took too much time (two to four hours). There were too many things to do, such as:

• Find out what changed on the client and on the server since the last synchronization of server and client.

• Merge the modifications done on the client.

• Compile server sources.

• Test server sources.

This had a further impact on other XP techniques, especially refactoring. Because integration was done infrequently, the refactorings were very large. We were therefore very often without running system versions, which hindered short releases. During the large refactorings, the test cases often broke down and had to be more or less rewritten after refactoring. This hampered the XP technique of testing.

We started to look for a more suitable integration method to restabilize our XP process.

We liked the idea of using an artifact to support continuous integration within our development team. But what sort of artifact would be suitable? Using one integration machine was unsuccessful, as were to-do lists.

We identified the following points as important for the continuous integration technique.

• Integration cycles must be very short. We consider a few minutes, no more, to be optimal. This enables us to realize smooth team development without adversely affecting other members of the team.

• Unit testing is essential. Ideal would be a tool that takes care of the correctness of all sources at every integration.

• The tool and the conventions should be as easy to use as possible.

We decided to develop a specialized tool, the JWAM IntegrationServer, as an extension to CVS, to provide our developers with a smooth way of dealing with continuous integration. We would, however, like to emphasize that any other source code management system may be useful for reifying continuous integration with the right set of conventions and values.