Restrict state

Work areas can be moved to the restrict state only when the release includes the driver subprocess. The work area moves automatically to the restrict state when the driver to which it belongs is restricted. If a work area in this state is removed from the driver, it returns to the integrate state. Otherwise, the work area remains in the restrict state until the driver to which it belongs is committed.

Commit state

Work areas can be moved to the commit state only when the release includes the driver subprocess. The work area moves automatically to the commit state when the driver to which it belongs is committed. At this point, all parts that were changed in this release to resolve the feature or defect are committed. The work area remains in the commit state until the driver to which it belongs is completed.

Test state

Work areas can be moved to the test state only when the release includes the test subprocess. When the associated driver moves to the complete state or when a work area is committed without a driver, the work area moves to the test state. The driver is then ready for formal testing in the speci®ed environments. Test records for the work area are created in the ready state when the work area moves to the test state. The work area stays in the test state until all test records are accepted, rejected, or abstained.

Complete state

The complete state is the ®nal state of a work area; the work area can no longer be used. If the test subprocess is not included in the release process, the work area moves directly to this state when the associated driver is completed or when the work area is explicitly integrated.

When a work area is completed, the feature or defect associated with that work area automatically moves to the verify or complete state. The defect does not leave the working state until the work area for that release is completed.

The states of drivers

Drivers monitor and implement the integration of part changes within a release. Those part changes are included in a driver by adding the work areas containing the changed parts to the driver as driver members.

Working state

The working state is the initial state of a driver. While the driver is in this state, it is not associated with any work areas and, therefore, contains no part changes.

If the release includes the driver subprocess, drivers can be explicitly created at any time.

Integrate state

Each driver automatically moves to the integrate state when the ®rst work area

Chapter 4. The states of TeamConnection objects 47

Page 67
Image 67
IBM SC34-4499-03 manual States of drivers, Restrict state, Commit state, Test state, Complete state