Continuous Integration

Teams practicing continuous integration seek two objectives:

• minimize the duration and effort required by each integration episode
• be able to deliver a product version suitable for release at any moment

In practice, this dual objective requires an integration procedure that is reproducible at the very least, and largely automated. This is achieved through version control tools, team policies and conventions, and tools specifically designed to help achieve continuous integration.

• As suggested above, the practice of continuous integration should not be confused with the tools that assist it (CI servers such as Cruise Control, Hudson, etc.). Continuous integration is first and foremost a matter of attitude rather than tools, and it relies on more than one kind of tool: tools for testing, tools for automating build processes, and tools for version control.
• Continuous integration aims to lessen the pain of integration by increasing its frequency. Therefore, “any” effort related to producing intermediate releases, and which the team experiences as particularly burdensome, is a candidate for inclusion in the team’s continuous integration process. (This is the reasoning that leads teams to continuous deployment.)

• 1993: the phrase “continuous integration” is already in use and thus predates what will later be known as Agile processes, for instance, an article contrasts it with “scheduled” integration, and recommends the latter, citing “lack of thorough testing” as one issue with continuous integration; this helps explain why the automated testing favored by Agile teams is an enabler for continuous integration
• 1996: Steve McConnell describes the “Daily Build and Smoke Test” technique, used at Microsoft for Windows NT 3.0 during the 1990s; the emphasis is not so much on the automation as on the frequency, the daily cycle being at that time considered “extreme”
• 1998: continuous integration is listed among the core practices of Extreme Programming
• 2000: an article by Martin Fowler provides perhaps the most complete description of the continuous integration practice available at that time
• 2001: Cruise Control, the first “continuous integration server”, is published under an open source license; it automates the monitoring of the source code repository, triggering the build and test process, notifications of the results to the developers, and archival of the test reports; the period 2001-2007 sees a large number of similar tools appear, leading perhaps to an excessive focus on tools over practice
• 2004: an article by Alberto Savoia proposes “Extreme Feedback Devices” such as lava lamps or dedicated monitors, to display the results of the most recent integration, an important innovation in CI

For most teams, continuous integration in practice amounts to the following:

• use of a version control tool (CVS, SVN, Git, etc.)
• an automated build and product release process
• instrumentation of the build process to trigger unit and acceptance tests “every time any change is published to version control”
• in the event of even a single test failing, alerting the team of a “broken build” so that the team can reach a stable, releasable baseline again soonest
• optionally, the use of a tool such as a continuous integration server, which automates the process of integration, testing, and reporting of test results

Look for a dedicated display in a prominent spot of the team room: this can be a normal monitor, an LED display, or even a lava lamp, with the sole purpose of reporting on the result of the most recent integration.

Observe also how the team responds to a broken build, suggesting that a defect may have been detected. If the team is aware of defects, but tolerates them or continues working on a product that isn’t in a releasable state, the term continuous integration no longer applies, irrespective of tooling!

• Continuous Integration, Martin Fowler (2006)