Continuous Integration Is Less About Tools Than It Is About Determination

ContinuousIntegration is less about tools than it is about determination. You can build a set of scripts and tools to help, but if the team is not determined to integrate continuously, it won't happen.

The most important tool is the source code control system. Make sure you can check out modules concurrently. Anybody can check out any module, no matter who else has it checked out. First one to check in wins. Everybody else has to do a merge. This puts a lot of pressure on people to check in frequently.

Institute a policy whereby you are not allowed to check in a module until you have integrated that module into the whole system and all existing UnitTests and AcceptanceTests are passing.

-- UncleBob on the XpMailingList

Just to emphasize a point:

Institute a policy whereby you are not allowed to check in a module until you have integrated that module into the whole system and all existing UnitTests and AcceptanceTests are passing.

In many situations it's not possible to pass acceptance tests as the tests are very time consuming and expensive to run. You can imagine Cisco's suite of tests taking weeks to run.

One solution is to divide the test suites up by how long it takes to run the test suite. You can require that every check-in pass every test in the "fast" test suite. You can run the "slow" test suite less often. Some companies run the "slow" suite hourly or daily. If there is an "extra slow" suite, it can be run every week, or every milestone. Shortening the time for a test suite reduces the CycleTime for the corresponding code changes. Short CycleTimes save time and money.

If the "fast" test suite covers enough of the code, and if you have continuous, rigorous code review, you can be confident that the "slow" test suite will usually pass.

SuggestedShorterName: ToolsOrDetermination?

EditText of this page (last edited March 25, 2006) or FindPage with title or text search