Multiple CCM Applications - A User Perspective

As described in Planning for multiple Jazz server instances the Jazz architecture allows for multiple instances of specific application servers, such as the Change and Configuration Management (CCM) application (Rational Team Concert), Quality Management (QM) application (Rational Quality Manager) and Requirements Management (RM) application (DOORS Next Gen). These application servers are registered to a common Jazz Team Server (JTS) to form a CLM Instance. See Multiple CCM Applications Best Practices for additional information.

What does this mean from a user perspective? The following sections will discuss this in more details for working with multiple CCM (RTC applications). Most of the information also applies if you have multiple other applications.

Web UI – User Perspective

First the user perspective in the Web UI.

Navigation

The home menu shows all applications registered to the JTS and projects the user is member of

If multiple applications are registered to a JTS, the context root of the application is presented for convenience. Navigation to elements is as usual

• Select the project area from the home menu
• Work inside the project area

The image below shows the Web UI user perspective. It shows multiple applications and all the projects of the user:

Please note, that dashboards can also show all projects in all applications accessible to a user.

Dashboards

Dashboards can collect data across applications

• Dashboard and Dashboard Mini allow to select the application
• Application specific dashboard widgets available after selection
• Add widgets with data from applications as desired

The image below shows that the Dashboard Mini can be configured to show all projects accessible to the user.

It is possible to add widgets from all registered applications. To configure a widget, select the CLM application and then select the widget from that catalog as shown below.

Eclipse Client UI – User Perspective

How does this look like from the perspective of a user that uses the Eclipse client?

The user connects to the applications needed

• Usually by a team invitation
• It is also possible to manually configure repository connections
• The user can rename connection if desired

The user can manage connected project areas for all repository connections, basically selecting which project areas are actively shown

• The client shows all selected project areas from all repository connections
• The context root of the application is presented for convenience

Navigation to elements is as usual

• Select a project area in the Team Artifacts view and create artifacts
• Create Work Item and other dialogs shows connected project areas and repositories

The Eclipse client shows the repository connections and allows to manage the connected project areas per repository connection. The selected project areas are presented in the UI and show the application for convenience. From a user perspective, this is transparent and irrelevant in the most cases.

The Eclipse client provides specialized menus, where necessary, that allow to select the projects to be looked at, regardless of the application they are on. This allows to create work items and other artifacts easily and without having to know which application manages the project area.

Multiple CCM Applications per CLM Instance

Looking at multiple CCM (Rational Team Concert) applications there are some special considerations when linking work items.

Work Item Linking – Work Item Link Flavors

RTC provides different link flavors that can be used between work items and other artifacts.

Work Item Link Types

These link types can only be created within one CCM application but across project area boundaries within the application context. Examples are:

• Parent/child ** Note: Roll up acoross project area boundaries is not supported by planning!
• Duplicate
• Related (Work Item)
• Change set to associated Work Item - this is a special link type that is used from the change set and only works within the local application

CLM Link Types

These link types can be created across application and project area boundaries. Examples are:

• Related Change Request
• Tracks (planning)
• Contributes To (planning)
• Change set to associated Change Request - this is a special link type that is used from the change set and works across project area and application boundaries.
• Links to artifacts in other CLM applications such as QM and RM

Configuring the CLM Link Structure

CLM links can not be just used between arbitrary project areas. It is necessary to define a structure between the various project areas and define which types of objects the project area provides to link to.

Associating project areas to be able to link artifacts within or across repositories using CLM link types, sets up the logical connections between project areas that need to link related CLM artifacts. An association defines which project area

• Provides which artifacts for linking to other project areas
• Uses which artifacts from other project areas for linking

CCM specific realtionships are:

• Related Change Request
• Tracks (planning)
• Contributes To (planning)
• Associate Change Request to a change set

The same administrative capability is available in the Eclipse UI. Setting up Lifecycle Projects creates these associations as well.

The image below shows the administrative Web UI and where to create the associations.

Creating Links - User Perspective

From a user perspective, there is really no difference between the different link types and flavors, except which destination project areas are provided in the selection dialog.

Based on the link type selected by the user, the UI provides the possible target project areas for linking. After selecting an available project area, it is possible to search for artifacts or to create new ones.

Work Item Links can only link to (local) project areas on the same application. The links can be created to any project area on the same CCM application that is available to the user. The image below shows the project areas the user has access to to create a work item link.

For CLM link types, the UI provides the targets based on the project area associations. The image below shows this as an example. Note, the destination project areas are different.

This has been designed this way since at least CLM 3.x.

The following image shows the Eclipse client dialog to create CLM links. It shows multiple project areas, because many provides associations are set up with the project areas. Only project areas that have such an association set up to this project area are shown.

• Creating CLM Links:
  

This image shows the Eclipse client dialog to create local work item links which only shows the project areas in the same repository. This dialog will show all active project areas that are in this repository.

• Create Work Item Link:
  

Planning – User Perspective

The RTC planning component considers the following link types:

• CLM Link types - Across or within one project area
  • Tracks/Contributes to

• Work Item Link types - within one project area
  • Parent/Child Link
  • Successor/Predecessor - only formal planning template

Parent/Child links can be created across project areas in the same application, however, the roll up of effort, complexity and other data related to planning really only works within one project area.

For cross project planning use Tracks and Contributes to CLM link types. They

• Track work items in other project areas in any CCM application
• Cross project plan shows roll up for effort planned in the other project area

The image below shows a cross project plan with Epic work items tracking effort in another project area using Tracks Links:

The Epics EP1-EP4 have a tracks relationship to the stories ST1...ST4 in a different RTC repository. Each story has estimated child execution work items such as tasks that it tracks in its repository. The planned effort for the tasks is accumulated on the plan items. See the planned effort and duration for ST1 and ST4 contributing to the over all duration. It is possible to use tracks/Contributes To relationships with any work item type, but it is most effective if a plan item/top level work item type such as a Story in this case is used as aggregating item for the execution items in the remote repository. This makes it easy to see where the effort is planned.

If the planning needs adjustment, look at the story that needs adjustment. The hover can provide with the information needed and allows to access details:

The plans that contribute to this plan can be configured to allow easier searching using plan links.

The image below shows the planned items and the execution items planned in the remote team area.:

Please note, for this to work it is necessary to create planned snapshots in the tracked plan to provide the plan schedule in the tracking plan.:

And it is necessary to set up the project associations to be able to create the links between the items.

It is useful to create plan links to make navigation between the plans easier:

RTC Jazz SCM

The RTC Jazz SCM system also provides special capabilities to work across repositories using Distributed SCM. How this looks for the user and some considerations are provided below.

User Perspective – WEB UI

This is not different to the normal use cases. The user can select the project areas and work within them on the available data.

User Perspective – Eclipse UI

The user sees the connected project areas and can perform the usual operations within the project areas regardless on which server these are located

• Create Streams
• Create Components
• Flow changes, create Baselines and Snapshots
• Create Repository Workspaces

SCM objects are global to a server. They are only associated to a project area or some other item by ownership. They are in principle accessible across all project areas.

Repository workspaces are owned by the user and not a project area.

When creating repository workspaces or streams, the user is provided with an option to choose the repository to store the stream or workspace with a sensible default.

The image below shows the user perspective when working with multiple CCM applications. The user can see the project areas and the related streams. The UI also indicates the application they reside. The user can see their repository workspaces and can see in which repository they reside.

RTC Jazz Distributed SCM

A repository workspace can be located in one application repository and flow to a stream in another application for example CCM->CCM1. From the user perspective, this is the usage of normal SCM operation. However, the data gets replicated (copied) between the application repositories and this is called Distributed SCM.

RTC provides Distributed SCM to support code versioning across multiple CCM application repositories. Distributed SCM

• Replicates changes sets across repositories by creating identical copies of change histories
• Supports the usual SCM user workflows, (flow target, accept, deliver)
• Requires both repositories to have the same or a compatible version of the CCM application on both ends
• Must be enabled on both servers as described in the liked article

The image below shows this activity in the advanced attributes of the CCM server.

In addition, users that replicate data across the applications to integrate changes

• Require the permission to replicate changes across repositories in the project areas that own the streams in each application

The image below shows how to set the permission for a role

What gets replicated in Distributed SCM?

• All required changes are replicated
• Only the current baseline is replicated
• Work Item links on change sets are replicated with the change set, but the work item only links back to the original change set

Assuming a topology similar to the image below:

This image shows how the different artifacts are stored in different repositories.

Distributed SCM supports the usual SCM user workflows across repository boundaries:

• Set Flow targets
• Accept changes
• Deliver changes
• Merging
• Baseline creation

However, some limitations apply.

RTC Jazz Distributed SCM Limitations

Limitations of Distributed SCM compared to SCM in one application are:

• Only the current baseline is replicated
• New changes in one repository are not automatically visible on the other remote repository ** Deliver the changes to a stream in the other repository
• Snapshots are local to a repository * Snapshot can not be created across multiple CCM repositories * Snapshots can’t be replicated (unlike baselines) ** Selecting a snapshot owner (stream) in a different repository is not possible

There are possible approaches to mitigate this:

• Manually accept additional baselines if needed, to bring them over
• Normal integration flow across repositories brings over latest changes
• Recreate Snapshots on the other server using replicated baselines

Automation might be possible using SCM commandline or API for the items above.

Operational Behavior Limitations

SCM related operation behavior (advisors/pre-conditions) that are built into the product only work in the local repository containing the change set and using the local "Associate Work Item" link. The image below shows the operations.

The most prominent are:

• Required Work Items and Comments
• Required Work Item Approval
• Required Work Items to Match Query (query has to be in the local repositrory)
• Restrict Change set delivery to Components in a Stream

If the change set and the work item are not in the same repository, the advisor “Required Work Items and Comments” only works in this configuration:

This allows making sure that a change set must have a work item or a change request linked to it. It does not allow making sure that a remote work item (considered a Change Request) is approved, planned for the current iteration and other constraints. See enhancement request: 396190: Allow the Source Control Deliver (server) Preconditions "Require Work Items and Comments" and "Require Work Item Approval" to work with associated change requests (OSLC Work Item Link Type) for additional functionality.

The other preconditions don’t work for associated Change Requests.

These all only work using

• Local Work Item Links
• Local Work Item Queries
• Local Streams

The best way to handle this is to keep the project containing the work items to organize the work together with the SCM data in the same application. Use Tracks Links for planning.

Administration Considerations

Scheduled Absences and Work Environment of the users are configured and maintained in each CCM Server. The image below shows the data for one user in one server.

This can lead to

• Inconsistent data in planning
• Overbooking users in planning

Consider a departmental approach if possible, where users contribute only to one CCM server for planned work Alternatively maintain the data consistently across all applications using automation.

Related topics: Deployment web home, Deployment web home

• Multiple CCM Applications Best Practices
• Jazz Source Control FAQ
• Easing into Jazz Source Control
• Update SCM Process Recipes
• Improved Gap Handling for SCM
• Flow changes cross repositories with Rational Team Concert
• Rational Team Concert Workshop – Distributed SCM and Shipping RTC SCM Change Sets Across Disconnected Networks
• Loading Content from a Jazz Source Control Repository in Rational Team Concert
• Controlling access to source control in Rational Team Control
• How to keep your streams flowing smoothly in Rational Team Concert
• Deleting Content From Source Control in Rational Team Concert

External links:

• IBM

Additional contributors: none