Continuous Integration
Continuous integration (CI) involves producing a clean build of the system several times per day.
Table of Contents
Continuous integration (CI) involves producing a clean build of the system several times per day, usually with a tool like CruiseControl, which uses Ant and various source-control systems. Agile teams typically configure CI to include automated compilation, unit test execution, and source control integration. Sometimes CI also includes automatically running automated acceptance tests such as those developed using FitNesse. In effect, CI means that the build is nearly always clean.
Continuous integration technique, tools, and policy
There are several specific practices that CI seems to require to work well. On his site, Martin Fowler provides a long, detailed description of what continuous integration is and how to make it work.
One popular CI rule states that programmers never leave anything unintegrated at the end of the day. The build should never spend the night in a broken state. This imposes some task planning discipline on programming teams. Furthermore, if the team’s rule is that whoever breaks the build at check-in has to fix it again, there is a natural incentive to check code in frequently during the day.
Benefits of continuous integration
When CI works well, it helps the code stay robust enough that customers and other stakeholders can play with the code whenever they like. This speeds the flow of development work overall; as Fowler points out, it has a very different feel to it. It also encourages more feedback between programmers and customers, which helps the team get things right before iteration deadlines. Like refactoring, continuous integration works well if you have an exhaustive suite of automated unit tests that ensure that you are not committing buggy code.
Skillful CI means that integration is never a headache, because your work reflects only slight divergence from the codebase. If the team must regularly deal with small-scale divergences, they never have to deal with truly scary ones. They also get the opportunity to discuss different design approaches on the day that they arise, because integrating that day brings them to the entire team’s attention.