MultipleCCMAppsUserPerspective < Deployment

<div id="header-title" style="padding: 10px 15px; border-width:1px; border-style:solid; border-color:#FFD28C; background-image: url(<nop>https://jazz.net/wiki/pub/Deployment/WebPreferences/TLASE.jpg); background-size: cover; font-size:120%">
---+!! Multiple CCM Applications - A User Perspective<img src="https://jazz.net/wiki/pub/Deployment/WebPreferences/new.png" alt="new.png" width="50" height="50" align="right"> 
%DKGRAY% Authors: [[Main.RalphSchoon][Ralph Schoon]] <br>
Build basis: None.
%ENDCOLOR%</div></sticky>

<!-- Page contents top of page on right hand side in box -->
<sticky><div style="float:right; border-width:1px; border-style:solid; border-color:#DFDFDF; background-color:#F6F6F6; margin:0 0 15px 15px; padding: 0 15px 0 15px;">
%TOC{title="Page contents"}%
</div></sticky>

<sticky><div style="margin:15px;"></sticky>

<sticky><div style="margin:15px;"></sticky>

As described in [[PlanForMultipleJazzAppInstances][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 [[MultipleCCMAppsBestPractices][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: 
<br />
<br />
     <img src="%ATTACHURLPATH%/01DashBoard_Home.png" alt="01DashBoard_Home.png" width="707" height="745" />

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.

<br />
     <img src="%ATTACHURLPATH%/02Dashboard_Mini.png" alt="02Dashboard_Mini.png" width="319" height="542" />

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. 

<br />
     <img src="%ATTACHURLPATH%/03ConfigureDashboard.png" alt="03ConfigureDashboard.png" width="788" height="292" />


---++ 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.

<br />
     <img src="%ATTACHURLPATH%/04Eclipse_Client_Perspective.png" alt="04Eclipse_Client_Perspective.png" width="551" height="744" />

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.

<br />
     <img src="%ATTACHURLPATH%/04Eclipse_Client_Perspective_Special_dialogs.png" alt="04Eclipse_Client_Perspective_Special_dialogs.png" width="319" height="133" />


---++ 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.

<br />
     <img src="%ATTACHURLPATH%/05_CLM_Links_Admin.png" alt="05_CLM_Links_Admin.png" width="907" height="541" />

---++++ 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.

 <br />
     <img src="%ATTACHURLPATH%/06_Work_Item_Link.png" alt="06_Work_Item_Link.png" width="612" height="293" />


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.

<br />
     <img src="%ATTACHURLPATH%/07_CLM_Link.png" alt="07_CLM_Link.png" width="515" height="448" />

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: <br />
     <img src="%ATTACHURLPATH%/CreateCLMLink.png" alt="CreateCLMLink.png" width="525" height="472" />

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: <br />
     <img src="%ATTACHURLPATH%/CreateWILink.png" alt="CreateWILink.png" width="574" height="447" />


---+++ 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 [[https://jazz.net/library/article/1152][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: 

<br />
     <img src="%ATTACHURLPATH%/CrossProjectPlan.png" alt="CrossProjectPlan.png" width="1186" height="469" />

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: 

<br />
     <img src="%ATTACHURLPATH%/CP_Hover.png" alt="CP_Hover.png" width="880" height="489" />

 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.: 

<br />
     <img src="%ATTACHURLPATH%/Tracked_Item_in_remote_plan.png" alt="Tracked_Item_in_remote_plan.png" width="1493" height="498" />

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.: 

<br />
     <img src="%ATTACHURLPATH%/Plan_Snapshots.png" alt="Plan_Snapshots.png" width="616" height="346" />

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: 

<br />
     <img src="%ATTACHURLPATH%/Plan_Links.png" alt="Plan_Links.png" width="692" height="439" />


---+++ RTC Jazz SCM

The RTC Jazz SCM system also provides special capabilities to work [[https://jazz.net/library/article/535/][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.

<br />
     <img src="%ATTACHURLPATH%/08_SCM_User_Perspective.png" alt="08_SCM_User_Perspective.png" width="492" height="652" />

---++++ 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 [[https://jazz.net/library/article/535/][Distributed SCM]].

RTC provides [[https://jazz.net/library/article/535/][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.

<br />
     <img src="%ATTACHURLPATH%/09_Enable_Distributed_SCM.png" alt="09_Enable_Distributed_SCM.png" width="608" height="80" />
 
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 

<br />
     <img src="%ATTACHURLPATH%/10_Permission_to_Replicate_changeSets.png" alt="10_Permission_to_Replicate_changeSets.png" width="572" height="208" />

What gets replicated in [[https://jazz.net/library/article/535/][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: 

<br />
     <img src="%ATTACHURLPATH%/11_DistributedSCM_Concept_Server_Setup.png" alt="11_DistributedSCM_Concept_Server_Setup.png" width="426" height="388" />

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

<br />
     <img src="%ATTACHURLPATH%/11_DistributedSCM_Concepts.png" alt="11_DistributedSCM_Concepts.png" width="729" height="355" />


[[https://jazz.net/library/article/535/][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 [[https://jazz.net/library/article/535/][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.
<br />
     <img src="%ATTACHURLPATH%/12_Operational_Behavior_Limitations.png" alt="12_Operational_Behavior_Limitations.png" width="377" height="274" />

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:

  <br />
     <img src="%ATTACHURLPATH%/Required_Work_Items.png" alt="Required Work Items Configuration" width="560" height="364" />

  <br />

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
[[https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/396190][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.
<br />
     <img src="%ATTACHURLPATH%/13_Admin_considerations.png" alt="13_Admin_considerations.png" width="810" height="617" />


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: [[DeploymentWebHome][Deployment web home]], [[DeploymentWebHome][Deployment web home]]

   * [[MultipleCCMAppsBestPractices][Multiple CCM Applications Best Practices]]
   * [[https://jazz.net/library/article/126][Jazz Source Control FAQ]]
   * [[https://jazz.net/library/article/539][Easing into Jazz Source Control]]
   * [[https://jazz.net/library/article/1468][Update SCM Process Recipes]]
   * [[https://jazz.net/library/article/1469][Improved Gap Handling for SCM]]
   * [[https://jazz.net/library/article/535][Flow changes cross repositories with Rational Team Concert]]
   * [[https://jazz.net/library/article/1399][Rational Team Concert Workshop – Distributed SCM and Shipping RTC SCM Change Sets Across Disconnected Networks]]
   * [[https://jazz.net/library/article/1016][Loading Content from a Jazz Source Control Repository in Rational Team Concert]]
   * [[https://jazz.net/library/article/215][Controlling access to source control in Rational Team Control]]
   * [[https://jazz.net/library/article/649][How to keep your streams flowing smoothly in Rational Team Concert]]
   * [[https://jazz.net/library/article/1006][Deleting Content From Source Control in Rational Team Concert]]

---+++++!! External links:          

   * [[https://www.ibm.com][IBM]]

---+++++!! Additional contributors: none
<sticky></div></sticky></div>
Attachments
Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
png	CreateCLMLink.png	manage	35.5 K	2016-06-24 - 14:43	RalphSchoon	Creating CLM Links
png	CreateWILink.png	manage	32.8 K	2016-06-24 - 14:44	RalphSchoon	Create Work Item Link
png	Required_Work_Items.png	manage	23.7 K	2016-08-01 - 14:44	RalphSchoon	Configuration
This topic: Deployment > WebHome > DeploymentPlanningAndDesign > PlanForMultipleJazzAppInstances > MultipleCCMAppsUserPerspective
History: r9 - 2016-08-23 - 10:01:43 - RalphSchoon
Copyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.