XP Practice: Continuous Integration

November 16, 2007 by Artem Marchenko

Integration is often one of the most difficult moments in software projects. In traditional waterfall development, the integration phase at the end of development can take a lot of time and reveal many design deficiencies. Things become easier if the organization adopts the practice of bi-weekly, weekly, or daily builds. The more frequently the system is built, tested, and verified, the earlier problems and deviations are found.

As with many other Extreme Programming practices, Continuous Integration is taking a known good practice to the extreme level. If it is good to integrate often, let's keep the code integrated always. The idea is to run the build and automated tests (at least the fast ones) whenever somebody checks code into the version control system. Usually it is done in automated manner by a tool such as CruiseControl. However, technically it can be done manually — some even find it beneficial and fun to do it without the automated tool support.

Links

• Continuous Integration by Martin Fowler.
• Continuous Integration on Wikipedia. The article is short, but the link list is large and good.
• Integrate often: A gentle introduction to extreme programming.
• CruiseControl: A home page of the most known and free tool for automating continuous integration.
• Continuous Integration: Improving Software Quality and Reducing Risk by Paul Duvall, Steve Matyas and Andrew Glover. Martin Fowler's Signature Series (non-affiliated link)

This page is a part of the Extreme Programming overview.

Permalink