Impacts of having Multiple CCMs in your RTC deployment

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.

Conclusion

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.

Advertisements

10 thoughts on “Impacts of having Multiple CCMs in your RTC deployment

  1. I suffer a couple of pains from have multiple servers in my deployment.

    The fact that projects cannot easily be moved between servers gives me some grief. I have projects that has surfaced over time and has been placed on different servers due to load balancing considerations that really should had been living in the same server.

    Having work items in one server and changesets in another is perfectly possible, but one of my absolute favorite features ‘Locate Changeset’ doesn’t support this use pattern.

    • Anders, I totally agree that there are many good use cases for moving projects around. There are a number of technical challenges in doing so especially when you consider a full CLM solution with all the links. It would be mice if we could at least copy a subset of artifacts to another repo/project to sort of seed a new project elsewhere (perhaps the next release is being managed by this other project). https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=245244 covers your locate change set use case though I see in the history you’ve already found it. Note the comment in there to submit a formal RFE. That would trigger a review by the RFE review board. For mow though, it is a limitation that needs to be added to our list. Thanks for the comment.

      • I updated the blog entry with the locate change set limitation as well as added a couple of others (limited link types between work items and more on deliver precondition limitations).

  2. Pingback: Impacts of having Multiple QMs in your RQM deployment | Tim Feeney's Blog on Jazz

  3. Pingback: Cross Project Planning with Rational Team Concert – the good, the bad and the ugly | Tim Feeney's Blog on Jazz

  4. Hello,

    What would be the best way to distribute the Project Areas across different CCM instances in a Component Based Development scenario?
    CBD in the sense, some Project Areas are developing common entities, which are then distributed (Source code deliveries) to other consuming Projects?

    Can we split the Component Teams to one instance and the consuming projects to another?

    • Hi, yes, that’s actually how I would distribute them. If the common entities and consuming projects could be further subdivided/grouped so that some groupings of common entities and consuming projects could be made, that would be another alternative. This all assumes the size of your deployment requires multiple CCMs.

  5. Hi Guys,

    Great blogs!

    One limitation that I believe was addressed with cross CCM implementation in 5.0.2 was the precondition requiring a descriptive change set being satisfied by a change request link. However, in my implementation we require change sets to be associated to approved work items. Unfortunately this is still not satisfied by the work items in the change request link. Do you have any idea if this funtionality is planned for a future release?

    Thanks,
    Jon

    • Jon, I am not aware of plans to address that limitation, however, I am confident it could be done as a custom plugin. That’s what we had to do with the precondition requiring a descriptive change set prior to it being addressed OOTB in 5.0.2.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s