Impacts of having Multiple QMs in your RQM deployment

Continuing from my previous post on Impacts of having Multiple CCMs in your RTC deployment I will now focus on what Ralph Schoon and I have found for Quality Management (QM) applications.

RQM and Reuse

RQM is intended to reuse as many test assets as possible, to reduce maintenance and improve productivity of the test teams.  Copying any of the assets creates a separate, editable copy, meaning for the same asset, you have to maintain the original and the copies in two (or more) places.  Copying should be kept to a minimum to maximize reuse within projects.

This focus on reuse encourages fewer projects, keeping like assets (by system, domain, segment, etc), in the same project area. 

The only functional reason to distribute project areas across multiple QM application instances is for scalability.  These too then should be organized to keep like projects together.

Ideally, to maximize reuse, avoid multiple QM application instances unless it is truly necessary for scalability.

Impact of Multiple QM Instances

The “Duplicate” capability – which enables you to replicate a single test artifact or an entire collection of artifacts – only supports duplication within the source project area or to a project area on the same application instance. You cannot use Duplicate to copy artifacts to a project area on another server.

However there is an ‘as-is’ command line RQM Copy Utility allowing copying of artifacts across servers. 

Built-in reporting and Rational Reporting for Developer Intelligence reports are limited in scope to one application server (Rational Insight would be required to report across QM instances).

Conclusion

As you can see, we only found a few differences (thanks to Marianne Hollier, Rational Services QM SME for these).  Ralph and I have a long history in Rational Team Concert so it is not surprising that our list there is longer.  As with the previous blog, if you are aware of other differences, please post a reply so I can augment the blog.

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.