Getting started 

The ultimate goal of continuous integration (CI) 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, though, it is best to start small and then incrementally add subpractices, as identified in the subsection that follows. For example, start with a simple daily integration build and incrementally add tests and automated inspections (code coverage, and so forth) to the build process, over time. As the team begins to adopt the sub-practices increase the build frequency. The following subpractices provide guidance in adopting CI.

Developer practices

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

• Don't break the build. Test your changes by using a private build before 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 (do not complete) the changes.

Integration practices

A build is more than a compile (compilation). 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 tests. 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 that there is a change to the implementation. Although a dedicated CI server is not essential, it will greatly reduce the overhead required to integrate continuously and provide the required reporting.

Common pitfalls

• A build process that doesn't identify problems. A build is more that a simple compilation (or its dynamic language variations). Sound testing and inspection practices, both developer testing and integration testing, must be adopted also 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 intention of continuous integration.

• Failure to commit defects to the CM repository. Ensure adequate testing by developers before making change sets available.