Incremental Integration

If you want developers to be able to test changes before publishing them, then allow them to build the entire product code independently to allow testing with the very latest base (not the latest Named Stable Base). undefined

To be applied before

 * Named Stable Bases is an input for Incremental Integration.

To be applied after

 * Incremental Integration can be combined with Private World.

Contents of following sections belong to the original Organizational Patterns website and have been divided into following parts: Context, Problem, Solution, Discussion.

Context
... 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 Named Stable Bases difficult to achieve when modules do not work together. Because we often develop with one Owner Per Deliverable, there will be occasional mismatches between units.

Problem
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 Private World. We need to find a way to make it possible to integrate without surprises.

Solution
'''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 Named Stable Bases, or the newest checked in software, at will.'''

Discussion
Assign the task of building the entire software system periodically: Named Stable Bases 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 Private World 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 Private Versioning 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.

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.