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.