Guideline: Promoting Builds
This guideline describes how to migrate a build up through a set of tiers from a private development area to a release area.
Relationships
Main Description

During iterative software development the team will create numerous Builds. A build is initiated by combining the work completed by one or more developers and resolving any conflicts that are encountered. Ideally a build is then subjected to a battery of tests to determine if it is of sufficient quality to move into production.

As a build progresses from development towards production it is beneficial to know two characteristics:

Build contents – identifying the elements and their versions

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

Verification Level – identifying what amount of testing that has been completed

  • Unit Tested
  • Integration Tested
  • System Tested
  • User Acceptance Tested
  • Production Ready
  • Production

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 work items
  • A build is generated clearly identifying the build contents
  • Testing is conducted
  • When testing is successful a build is marked with the appropriate verification level

Ultimately all required testing is complete and the a new system version is ready for production.

It can also be beneficial to isolate work being performed at the different stages using different Workspaces. This ensures that the effort of testing a build is applied to the correct version and also allows developers to continue working on the next build while the previous build is being tested.

A promotional 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 build passes the previous stage. For example you would not commit the resources to User Acceptance test a build until it passes both integration and system tests.
  2. Helps to ensure that a build 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 build (Integration Tested build, for example) in relative isolation from destabilizing changes from other developers
More Information
Concepts