During iterative software development, the team creates numerous Change Sets that are combined into a Build. A build is initiated by combining the work completed by one or more developers and resolving any conflicts between those changes. Ideally a build is then subjected to a battery of tests to determine if it is of sufficient quality to move into production.

As the changes progress from development towards production, its beneficial to know two characteristics:

Test Context – identifying the elements and their versions that are tested together

• What changes are in this build (completed work items)
• What changes are partially in this build (work items that are partially complete)
• What changes are not in this build (work items that are not reflected at all in this build)

Verification Level – identifying what amount of testing is complete.  For example,

• Unit Tested
• Integration Tested
• System Tested

The promotion lifecycle coordinates and synchronizes the efforts of the development team. This lifecycle consists of the following steps:

• Changes are introduced into the system in the form of completed Change Sets
• A build is generated clearly identifying the changes included in the build
• Testing is conducted
• When testing is successful the changes are marked with the appropriate verification level through labeling, baselining or other related techniques.

Ultimately all required testing is complete and a new system increment is ready.

Separate Workspaces are often used as the context for each level of testing. As changes are added to the Workspace, it is verified for consistency and tested. This ensures that the effort of testing a build is applied to the correct set of changes, makes the context for the tests stable, and also allows developers to continue working on the next build while the tests are being conducted.

A change promotion lifecycle such as this offers three key benefits

1. Reduces effort because there is no reason to execute the tests in the next stages until the changes passes the previous stage. For example you would not commit the resources to system testing a build until it passes developer tests.
2. Helps to ensure that a change which is moved into production has been subjected to the appropriate level of testing first.
3. Simplifies debugging since developers can base their work on a proven set of changes in relative isolation from destabilizing changes from other developers

For an example of this approach see Development Sandboxes: An Agile "Best" Practice.