Filter
Top Products
The states of work areas
A work area is a storage area where you can work on the parts in a release without
affecting the ″official″ versions of those parts. A work area can be associated with a
specific defect or feature, but it does not have to be. These attributes can affect the
state of a workarea:
trackfixhold With the trackfixhold attribute and the fix subprocess, a workarea will
remain in the fix state rather than moving to the integrate state when the
final fix -complete command has been issued. A workarea -integrate
command must be issued to move the workarea into the integrate state.
trackcommithold If an environment list exists for the release associated with the work areas,
the automatic transition to the test state can be disabled by including the
-trackcommithold attribute in the release process. A workarea -test
command must be issued to move the workarea into the test state.
tracktesthold With the tracktesthold attribute and the test subprocess, a workarea will
remain in the test state rather than moving to the complete state when the
final test is marked. A workarea -complete command must be issued to
move the workarea into the complete state.
Approve state
When a work area is created, it goes to this state if the release includes the
approval subprocess. TeamConnection creates an approval record for each
user on the release’s
approver list
. Each approver indicates their evaluation of
the changes in their approval record:
v Accept that work should continue
v Abstain if unable to assess if work should continue
v Reject if work should not continue
When all approval records are marked as abstain or accept, the work area
goes automatically to the fix state. If any approval record is marked as reject,
the state of the work area remains at approve. You can change rejected
approval records to accept or abstain.
Fix state
If the release does not include the approval subprocess, work areas for the
release begin in the fix state.
While the work area is in this state, parts are checked out to the work area,
changes are made to these parts, and builds are done to verify the accuracy of
the changes.
If the release includes the fix subprocess, any fix records created for a defect
or feature move to the active state when a part change is associated with the
work area for the defect or feature. A fix record monitors the part changes
within a single component. Fix records provide a mechanism for reviewing all
part changes that apply to components before integrating those changes with
changes made for other defects and features.
Chapter 4. The states of TeamConnection objects 45