Several packages that enable deployment tracking have been added
to IBM Rational® ClearQuest®.
The following deployment tracking packages have been added to IBM
Rational ClearQuest:
- The DeploymentTracking package, which supports the deployment approval
process.
- The TPM package, which can be used to associate your release with
the location of an IBM Tivoli Provisioning Manager server. This package need
only be applied if you are interested in creating an integration between Rational ClearQuest and Tivoli
Provisioning Manager. You can use the TPM package functionality to add a URL
link to the Tivoli Provisioning Manager Web user interface to your deployment
record, providing a simple user interface integration between Rational ClearQuest and
Tivoli Provisioning Manager.
- The eSignature package, which supports requiring e-signatures when
approving or rejecting an approval record.
- The AuditTrail package, which enables you to track to keep track
as to what, when, and by whom fields of Approval records and Deployment records
were modified.
- The Email package, which supports sending e-mail notifications
to approvers of a release when an approval has been submitted, approved, or
rejected.
- The BuildTracking package, which enables traceability between the
build and deployment phases.
Record Types
Applying the DeploymentTracking package to your
Rational ClearQuest schema
adds the following record types:
- DTDeployment
Each deployment record represents a single deployment.
Each deployment record has a field that indicates to which environment it
may be deployed. Deployment details are described in the deployment unit XML
file that the deployment record references.
- DTApproval
This record type represents an approval for a deployment.
Approvals can reference at most one deployment record.
- DTEnvironment
Each environment represents a different phase of
testing. You may create a number of environments for multiple testing phases
that your software must go through before release; for example, you could
have unit test, functional test, system test, and integration test environments.
- DTRole
Roles indicate which users have permissions to approve
a deployment into a particular environment. Rational ClearQuest users
can belong to more than one role.
- DTRelease
Each release record models a release at the deployment
level. Each release has a set of roles authorized to approve deployments,
and in UCM environments, enables multiple UCM projects to be modeled as inputs
to a single deployment. A release will have a series of deployments over the
course of a release.
TPM package record types
Applying the TPM package to your
Rational ClearQuest schema
adds the following record types:
- TPMServer. Each TPMServer record contains basic information about
a Tivoli Provisioning Manager server. There will be one instance of this record
type, and likely only one record, for each Tivoli Provisioning Manager server
in your environment. When a release is defined, the release can be associated
to a TPM server record. Each deployment record with a release record that
references a TPM server will contain a URL reference to the TPM Web interface,
providing deployment records with a simple user interface integration.
- TPMWorkflow. This record represents a TPM workflow. This is a proxy
for information in TPM. This record is being added to support integration
with TPM in upcoming releases. Workflow records reference 0..* deployment
records.
BuildTracking package record types
Applying the BuildTracking package to your
Rational ClearQuest schema
adds the following record types:
- BTBuild. This record type enables you to track the state of your
build. Information you can track includes the start and end times of your
build, whether your build was successful or not, what release your build is
associated with, and where your build log is located.
Deployment record state types
The following are requirements for setting state types when using
Rational ClearQuest for deployment
records:
- You must assign each state to a state type.
- You must have one state definition of the following state types in your
deployment record type:
- Ready. This state indicates that the release is ready to be deployed to
the current environment.
- Deployed. This state indicates that the release has been deployed to the
current environment.
- Retired. This state indicates that the release has been deployed on all
the required environments
- Failed. This state indicates that there are errors in the deployed release
and that further deployment of this release has been terminated.
- The state transition path is Ready->Deployed->Retired.
- You cannot set the initial state of deployment records to Retired or Failed.
The initial state should always be Ready.
Approval record state types
The following are requirements for setting state types when using
Rational ClearQuest for approval
records:
- You must have one state definition of the following state types in your
deployment record type:
- Submitted. This indicates that the approval record has been submitted.
- Approved. This indicates that the approval record has been approved.
- Rejected. This indicates that the approval record has been rejected.
- The state transition path is Submitted >Approved or Submitted > Rejected.
In addition to the state types and transition model described here, you
can also create your own customized state types and state transitions.
Build record state types
The following requirements are for setting state types when using
Rational ClearQuest for build
records:
- Submitted. This indicates that the build has been started.
- Completed. This indicates that the build has completed without errors.
- Failed. This indicated that the build has failed.
- Retired. This indicates that this build record is no longer relevant.
The state transition path is: Submitted > Completed, Submitted >Failed,
Completed > Retired, Failed > Retired.