ALM in a Rational® ClearQuest® MultiSite environment

The role-based record types in an ALM schema enable more effective globally distributed development. A team of users can work on specific records associated with a Request or Task based on their roles, which prevents conflicts when multiple users need to update the same record.

In addition to helping establish a role-based change management system, a common workflow can also help address mastership and replication requests in a distributed environment. For example, if a user logs in to a replica that resides in Bangalore, when the user creates a new Task, the Task is mastered where the Developer owner is located. The Task is created on the Bangalore site and then replicated. The initial Task mastership is determined by the default Developer owner, regardless of where the Request is mastered. Note that:

A Request has to replicate to all sites to be visible.
A Request contains references to the associated Tasks, and Tasks contain a reference to the Request.
Each Task is mastered at the site of the default Developer owner once the Task is Opened. The Task is mastered at the site of the QE Lead once the Task is Activated.
The Activity for an associated Task is mastered at the site of the Owner once it is Opened or Submitted. The Assigned Developer is the Owner of the Developer Activity. The default Developer owner can be determined by a Project, Component or Subcomponent field value. The default Doc owner is the owner of the Doc Assess Activity, and the default QE owner is the owner of the Test Activity.

The ALM workflow paradigm provides clear support for parallel, distributed development. For example, Tasks created to address Requests can be being reviewed for progress by Requestors when Developer Activities are Complete but not Tested or Assessed for documentation. Some Developer Activities can be Completed and others still Opened while Testing can be done on the work that is complete to date.

Sorting records in a MultiSite clan cannot be done in way that users running the same query at different sites see the same sequence of records if the sort fields on a query have more than one record with the same sort key or concatenated sort key values. For example, if you sort by Name and two records have the same Name then users at each site may not see the two records in the same sequence at both sites. If you use the record ID as a second sort field, note that the IDs are allocated blocks of IDs that may not reflect the order of the records being submitted. If you use the History filters (History.action_name in ('Copy_Record, 'Import')OR History.old_state = 'no_value'), you can get the first History record for any record for sorting to find the absolute sequence in which any two records enter a clan. You can use History.expiration_timestamp IS NULL to get the last History.Action.