My colleague Ralph Schoon (rsjazz.wordpress.com) and I are working on documenting the motivations, tradeoffs, pros and cons when deploying multiple instances of the same Jazz application. That is, cases where you have more than one CCM server and/or more than one QM server registered to the same JTS.
Our findings and guidance will eventually make its way to the Rational Deployment Wiki and an Innovate 2014 presentation. I wanted to begin to surface some of the findings now to perhaps uncover some things we haven’t yet.
Jazz allows Multiple CLM Applications
It is possible to deploy multiple instances of the same application each registered to the same JTS. Today this is possible for the Change Configuration Management (CCM) and Quality Management (QM) applications. The Requirements Management application does not yet support multiple instances yet, however, follow RM Plan Item 76315 to track progress towards that.
There are several motivations for having multiple instances.
- Isolate a department or subcontractor
- Capacity planning given the amount of concurrent users supported by the application instance and or usage model require multiple application servers
- An organization would like to separate confidential data from non-confidential data
- Funding model for projects requires segregation
Multiple CCM Applications
The following sections describe functional/behavioral differences when working with Rational Team Concert capabilities on one instance versus when multiple instances exist.
Impact on Work Items
Copying/moving of Work Items to another Project Area is only possible within the same CCM repository
The Eclipse “current work item” functionality doesn’t work when the work item is in another repository.
The only link relationships between work items in different CCM repositories are ‘Related Change Request’ and ‘Tracks’.
Impact on Planning
Those working in multiple CCMs will need to maintain their work allocation and scheduled absences in each CCM where they have assigned work. Correct and complete allocation and time off entry ensures proper load and progress calculations in plan views.
Cross project plans allow one relationship type to show as a tree view. You can choose either tracks or parent/child, but not both. As mentioned in the work items section, parent/child relationships are not supported across CCM repositories. Therefore, cross project plans cannot show parent/child hierarchy relationships.
Impact on SCM
It is possible to add a component located in another CCM repository to a stream. This creates a new component in the local repository and uses distributed SCM to copy the change sets over. Integrating local changes back requires using a repository workspace or stream and to deliver the changes back to the remote repository. Flow targets between streams are supported and it is possible to deliver or accept changes from a stream to another in the pending changes view.
Snapshots/baselines are local to a repository; it is not currently possible to select an owner in a different repository.
When associating a change set to a work item in another CCM repository, use the ‘associate change request’ gesture to make the association rather than ‘associate work item’.
The precondition requiring change set to be associated to an approved work item only works for work items in same CCM repository as change set. Similarly, the precondition requiring a descriptive change set cannot be satisfied by a change request link. Most out of the box deliver preconditions can only be satisfied by work item links.
The locate change set capability only works when finding work items/change sets in the local repository.
Ralph and I welcome your comments to let us know if we have missed anything. In subsequent posts I plan to cover impacts when you have multiple QM and JTS applications. One day we’ll have support for multiple RM and I’ll post about that too. Other relevant topics would also include strategies for distributing projects across multiple instances as well as how do you know how many users/projects can one instance handle.