Incremental Integration

Contribute to software one piece at a time, gradually, avoiding waterfall and other precipitous changes.

...some organizations have infrequent integrations which reflect large changes. This can make it difficult for the integration release to work as expected, complicate the process of work integration and make NamedStableBases difficult to achieve when modules do not work together. Because we often develop with one OwnerPerDeliverable there will be occasional mismatches between units. 

✥ ✥ ✥

For iterative development to work well, it is necessary to make sure that components work together.

Subsystems get developed at different rates. Developers work in a PrivateWorld. We need to find a way to make it possible to integrate without surprises.

Therefore:

Provide a mechanism to allow developers to build all the current software periodically. Developers should be discouraged from maintaining long intervals between check-ins. Developers should also be able to build against any of the NamedStableBases, or the newest checked in software, at will.

✥ ✥ ✥

Assign the task of building the entire software system periodically: NamedStableBases suggests intervals no more frequent than a week. This periodic build should be checked for interface compatibility (does it compile?) and testing (does it still work?) 

Encourage developers to build from files that are likely to be in the release (for example, perhaps the newest code in the revision control system is trunk) to anticipate, and allow time to correct for, incompatibilities. The goal is to avoid a "big bang" integration and allow the developmental build to proceed smoothly. 

This can be combined with PrivateWorld to ensure that the changes integrate with a copy of the current development system. There are issues relating to the size of the software system (some systems take quite a while to build, making frequent integrations difficult). Balance this with PrivateVersioning to allow the developer some leeway on deciding when to integrate their new code into their environment, but do not put it off for too long. 

Example:

The developer's work space could be updated (at the developer's request) to a named stable base from the project repository approximately weekly. The developer will also retrieve the current files from the repository to anticipate how the current changes in the work space will work with files that may later be in the baseline.