Roadmap: How to Adopt the Staged Integration Practice
This roadmap describes how to adopt the Staged Integration practice.
Main Description

Getting Started:

The ultimate goal of integration is to minimize the time between injecting a change into the code base and creating a working build that includes that change. The ideal is to perform continuous integration. However, as systems become larger and components are developed by separate subteams, it becomes necessary to introduce staged integration.

Staged integration requires coordination between components and component teams. If your system is complicated enough to require a staged integration approach, then you will typically require a dedicated person or team to be responsible for this coordination. In order to allow the system build to compile and evolve to include increasing levels of functionality, the integrators need to understand the following: the architecture of the system, the dependencies between components, and the sequence of development.

Developer practices

  • Make changes available frequently. For integration to be effective, component teams need to regularly qualify subsystem builds and make them available for higher level integration. Keep change sets small, complete, cohesive, and available for integration, so that they can be completed and tested in a relatively short time span.
  • Don't break the build. Coordinate changes so that system builds evolve, rather than break and have to be fixed.
  • 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.

Common pitfalls

  • A build process that doesn't identify problems. A build is more that a simple compilation (or its dynamic language variations). Adopt sound testing and inspection practices, both at developer testing and integration testing levels, so 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 continuous integration. Use staged builds to 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.