ClearCase to RTC, an enterprise solution for integration?
Hi,
I am looking for some advice on how to properly transition to RTC from an existing ClearCase environment using the CC synchronizer. This solution needs to be viable at an enterprise level. The short term goals are to have most of the work done in RTC, while periodically syncing back to ClearCase. The synchronizer was chosen because fail-over in case of failure (risk mitigation) is a must; ClearCase is currently integrated with tons of other products and builds are done off of ClearCase - even if the work is done in RTC. Eventually, the longer term goal would be to have the majority of the traffic to ClearCase, while only syncing for big builds. Making sure the connector is reliable is very important, so random syncing to test throughout the day is a necessity. The even longer term goal is to complete the transition to RTC. This will not be possible unless a solid roadmap on how to get there is provided. With that background information, I was hoping to get answers to some questions. Also, aside from getting them answered, it would be nice to hear from the Jazz developers (or anyone that can share their story) that have had to tackle this. How did you transition? What worked best? I feel something like this should exist, or maybe it does and I have not found it. There are plenty of answers on what I can/can't do, but nothing on experiences. 1. Who should maintain the ClearCase Synchronized Streams? Currently, there is one machine that runs the sync engines. If some new files need to be synchronized, should developers have to ask the 'RTC-CC Sync Admin' to set up/update the synchronized stream? Should developers have access to this machine, or even to create/launch synchronization streams from their own desktops? 2. Related to the previous question, how well is the synchronizer going to scale given an environment with hundreds of ClearCase streams? Launching one Build Engine for every synchronized stream will eventually get messy and hard to manage. For now, only one is running per project but eventually there might be 5, 15, even 20 needing to be ran simultaneously - is this viable? It seems this would be very difficult to manage from one machine even if only the streams you need to do work on are running- developers need to ask the 'RTC-CC Sync Admin' for an engine to be started every single time. 3. How well does the synchronization engine support refactoring? Some light testing has been done, and all seems to work (rename/delete/move). For instance, I have a project started from scratch in RTC and I want to port it over to ClearCase by syncing to an empty CC Stream. Are we in the right track? Most of the knowledge around this comes from the articles, blogs and infocenter documentation on this site ( http://jazz.net/library/article/68 , http://jazz.net/library/article/502). We want to make sure we are not missing anything, and are following a solution that will be scalable, reliable and supported. Thanks! |
2 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 22 '10, 2:23 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
On 11/22/2010 11:23 AM, david987 wrote:
1. Who should maintain the ClearCase Synchronized Streams? Currently, To create a ClearCase Synchronized stream, you need a ClearCase administrator who has RTC training (because, as you could guess, creating such a stream requires knowledge of both ClearCase and RTC). But after the CC Sync stream has been created, then anyone with access to a host machine with both RTC and ClearCase MVFS installed could add new folders to be synchronized into an existing CC Sync stream. They would just use the "select files to synchronize" wizard. 2. Related to the previous question, how well is the synchronizer You should only be synchronizing the main integration stream, not any of the individual development or team streams. If you have multiple releases, then you would probably need one sync stream per release (but that should be a handful of synchronized streams, not dozens, much less, hundreds). It's not a question of managing the sync engines (you'd just add them as services that automatically get started when the sync host is started). It's a question of properly managing merging between the various streams ... your "findmerges" will not be able find the appropriate common ancestors if there are too many synchronization streams, so you'll find yourself redoing merges on both sides. 3. How well does the synchronization engine support refactoring? Some All refactoring operations (rename/delete/move) are fully supported by the synchornizer. In fact, it even supports the "restore" operation, where you delete a file and then bring it back. It will "bring back" the appropriate element on the other side. Are we in the right track? Most of the knowledge around this comes You are on the right track, except for the number of sync streams ... you'll want to keep that down to a handful. For this, I'd recommend a blog Dan wrote on this last year: http://dtoczala.wordpress.com/2009/12/11/jazz-progressions-approaches-to-mixed-tool-implementations/ Cheers, Geoff |
Just wanted to jump in and echo what Geoff said. You only want to sync your main integration (or release) streams. That keeps the number of things that a Jazz/CC Admin needs to track to a minimum. Teams that are "consuming" components will only want components that are tested to some level of confidence. Teams that are developing components will only want tested components available to the other teams. In practice, this approach seems to work the best.
My blog posting goes over some of this (and the ideas in that blog were shamelessly stolen from Geoff). If you still have questions about how to do this for an enterprise deployment of RTC, I would contact your IBM/Rational services folks. They provide architectural services to address the issues involved with large scale deployments. |
Your answer
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.