Rational® Change
Distributed is the distributed change request tracking package. A
change request is a problem or issue that is entered and tracked through
to completion by using Rational Change
Distributed.
To work on change requests in a distributed
environment, choose one of the following solutions.
- Central CR Server.
With central CR server, you have a single
change request database and a Rational Change
server. Change requests are submitted and maintained in this database.
Developers working in separate engineering databases can create tasks
associated with change requests in that central CR database. In this
way, you do not need to replicate change requests across databases.
All change request data is held in a single database.
- Distributed change requests.
The distributed change requests
usage does not have a single change request database. Instead, change
requests are replicated between development databases as required.
Developers can create tasks associated to change requests and resolve
the change requests in their local engineering database.
The advantages of central CR server are ease of use, and
developers do not have to wait for control of a change request to
be replicated before they can modify or work on the change request
in their local database. The advantage of distributed change requests
is that all of the data that a developer needs to work on is held
locally. Keeping data local might make the data more resilient against
network outages.
The following topics describe how to use distributed
change requests. For information on central CR server, see the Rational Change information
center.
Rational Change Distributed
enhances change management functionality in the following ways.
- Change requests and tasks in any state are eligible
for replication.
- A given change request or task can be modified in
only one database at a time within a DCM cluster. This operation is
controlled by the modifiable_in attribute and security
rules.
- Permission for the controlling database to modify
or promote a specific change request or task can be handed over to
another database in the DCM cluster.
- Change request and task resolvers can be chosen
from a list that can include external database users listed in a Rational Change file.
- Transfer sets can define a change request scope
that includes a change request query. The change request scope defines
whether change requests are included. If they are, the change request
scope also defines whether change requests include their associated
tasks. If they do, the change request scope also defines the associated
objects of each associated task.
- The change request scope and change request query
of a transfer set can be defined using the GUI or CLI.
- Transfer sets can define whether the change request
scope is cumulative or not. When disabled, the indirect change request
members of the transfer set are precisely defined by the change request
query and scope. Any members that no longer match the query are removed.
When enabled, the scope query adds to the existing indirect change
request members and all existing change request members are preserved.
The option is typically enabled when change requests are replicated
on a selective basis (using a specific change request query). The
option is enabled especially when intermediate hub databases are used.
This operation allows an object that was once replicated to a database
to continue to be updated even though it is no longer found by the
change request query defined for the transfer set.
- Only tasks that are assigned to a developer and
modifiable in the current database can be used as the current
task for the developer. These tasks can also be used to check
out or check in objects. Possibly, such
tasks were created and assigned in a different database and replicated
to the current database.
- When a task is selected in a DCM-enabled database,
it is displayed in the dbid#nnnn format. dbid is
the database ID, # is the DCM delimiter, and nnnn is
the task number. This data appears in Rational Synergy task
dialog boxes and certain fields in Rational Change.
- Parent-child and related change requests are supported.
You can configure Rational Change
Distributed in the following ways.
- Transfer sets can exclude non-modifiable tasks.
By default, tasks in any state are eligible to be included in a transfer
package. If needed, the transfer set definition can exclude all incomplete
tasks.
- Transfer sets can exclude imported objects. By default,
transfer sets allow a database to generate a transfer package that
includes objects that were received from other databases. This operation
allows replication through a chain of such databases. If this option
is disabled, the database in which the object was generated must always
perform the replication to the receiving databases of the object.
- DCM model parameters allow Rational Change Distributed behavior to
be adapted for complex Rational Change
Distributed methodologies.