Agile SCM – Build Management for an Agile Team

• of the development team (for production use).

Private System Build

The Private System Build is used by the individual developer working on an isolated development task to verify the consistency and correctness of their changes before committing them to the codeline where they will be visible to the rest of the development team. The developer creates a Private Workspace and populates it with the latest working versions from the codeline in order to begin work on their development task. After making changes in their Private Workspace, the developer needs to ensure that the source changes work correctly and won't "break the build" for the rest of the team. The usual sequence of steps for doing this is part of a Private System Build:

• Perform a Workspace Update to make sure the changes in your workspace incorporate the most recent changes that have been successfully integrated to the codeline from other developers. This may cause some files to be populated with new versions in the workspace. Other files may have parallel changes and will need to be merged to reconcile any potential conflicts.
• Perform a build (usually an incremental build, but sometimes a full build) and run tests to ensure the resulting components build and execute correctly.

The above might happen multiple times during a development task, at progressive "checkpoints" of development functionality for a requested feature, fix or enhancement. Or it might happen once at the very end of a (small to moderate) development task, prior to committing one's changes to the codeline.  In either case, it should always happen prior to committing changes to the codeline. Some kind of synchronization mechanism is often used to serialize commits so that only one person commits their changes at a time (that is another set of patterns for another article).

So the organizational scope (visibility) of the private system build is the individual developer, and the frequency is one or more times per development task. The purpose is to insulate the development team from any problems that might impede the progress of other team members and active development tasks. By ensuring the changes for a single task are correct and consistent with the latest stable state of the codeline, the impact to the team and the codeline is minimized. The team is able to be more "agile" and to integrate their changes more smoothly in a regular and frequent fashion.

Integration Build

The Integration Build is used by the integrating developer (or integrator) to incorporate the most recently completed development tasks into a single, stable, consistent and correct result. The result of a successful integration build is also what is used during a Workspace Update to synchronize the state of an in-progress development task with the latest stable state of the codeline.

An integration build is preferably a full build (if time and bandwidth allows) whose results visibly impact the progress and coordination of the entire development team and all the active development tasks at that time. The frequency of an integration build may be as often as one per development task (at the end of each task) or may be every few tasks (or even daily/nightly). In some cases, there may be two "flavors" of integration builds: one that is done after every development task and does only an incremental build (and possibly runs only a subset of tests), and one that runs daily or nightly and does a full build and runs a more complete set of tests. In either case, the purpose of the integration build is to centrally coordinate and synchronize all ongoing work in small bits and