Getting Started

The ultimate goal of continuous integration is to integrate and test the system on every change to minimize the time between injecting a defect and correcting it.  If the team is new to continuous integration however, it is best to start small and incrementally add sub-practices as identified below.  For example, start with a simple daily integration build and incrementally add tests and automated inspections (code coverage, etc.) to the build process over time.  As the team begins to adopt the sub-practices increase the build frequency.  The following sub-practices provide guidance in adopting CI.

Developer Practices

Make changes available frequently.  For CI to be effective, Change Sets should be small, complete, cohesive and available for integration.  Keep change sets small so they can be completed and tested in a relatively short period of time.

Don't break the build. Test your changes using a private build prior to making your changes available.

Fix broken builds immediately.  When a problem is identified, fix it as soon as possible while it is still fresh in your mind. If the problem cannot be quickly resolved, back out the changes.

Integration Practices

A build is more than a compile.  A build consists of compilation, testing, inspection and deployment.

Provide feedback as quickly as possible.  Automate the build process so that it is fast and repeatable and so that issues are identified and conveyed to the appropriate person for resolution as quickly as possible.

Automation

Commit your test scripts to the CM repository so they are controlled and available to the rest of the team. Automated testing is highly recommended, both for developer tests and integration test.  Tests need to be repeatable and fast. 

Commit your build scripts to the CM repository so they are controlled and available to the rest of the team. Automated builds are highly recommended, both for private builds and integration builds.  Builds need to be repeatable and fast.

Invest in a CI server.  The goal of continuous integration is to integrate, build and test the software in a clean environment any time there is a change to the implementation.  Although a dedicated CI server is not required, it will greatly reduce the overhead required to perform continuous integration and provide the required reporting.

Common Pitfalls 

The most common pitfalls in implementing continuous integration include:

A build process that doesn't identify problems.  A build is more that a simple compile (or its dynamic language variations).  Sound testing and inspection practices, both developer testing and integration testing, must be adopted as well to ensure the right amount of coverage.

Integration builds that take too long to complete.  The build process must balance coverage with speed.  You don't have to run every system level acceptance test to meet the intent of CI.  Staged builds will provide a useful means to organize testing to get the balance coverage and speed.

Change sets that are too large.  Developers must develop the discipline and skills to organize their work into small, cohesive change sets.  This will simplify testing, debugging and reporting.  It will also ensure that changes are made available frequently enough to meet the intent of continuous integration.

Failure to commit defects to the CM repository.  Ensure adequate developer testing prior to making change sets available.