CC/CQ connectors - real world usage?
![]()
We are currently using CQ and CC with UCM integration. Looking @ using RTC for distributed teams, and using the CC and CQ connectors built into RTC for synchronizing code/work items.
1. Is there anyone who uses these connectors in a production environment? I'm looking for any anecdotes for how well they *really* work. As these are "connectors" between disparate systems, our management is somewhat leery about these being fragile and causing more issues than they solve. 2. Let's say we've got 50 developers using RTC, and all 50 of those have code that will be synchronized into CC. We will of course have the 50 developer licenses for RTC here. Are there any additional licenses that will need to be purchased? IE, I've seen in our trial that there is a "ClearCase Connector license", but I am unsure if we need just one of those across the board, or one per user? 3. Same question as #2 for CQ... How many licenses? 4. When code is sync'ed over to CC with the UCM integration, does it handle picking up the correct CC/CQ "activity" so that in CC, another dev/CM person can see what CQ record is associated with the code commit? Thanks in advance, Mike Johnson |
12 answers
![]()
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 06 '09, 9:36 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Some comments below:
micjohnson997 wrote: We are currently using CQ and CC with UCM integration. Looking @ For the ClearCase Synchronizer, it's pretty easy to find out how well it will work in your environment, since the initial sync is the most expensive, and will exercise most of the logic in the component. Make sure that you read the CC/CQ Connector tech note: http://jazz.net/library/technote/68 2. Let's say we've got 50 developers using RTC, and all 50 of those The RTC server comes with all the CC Connector licenses that you will need, so they don't have to be purchased separately, and you do not have to use any of your developer licenses for CC synchronization. 3. Same question as #2 for CQ... How many licenses? You only need one CQ Connector license, and you get that included in your RTC server. 4. When code is sync'ed over to CC with the UCM integration, does it The CC Synchronizer does not try to replay all of the activities that have occurred since the last synchronization. Instead, it just brings over the current "tip" of the ClearCase stream being synchronized, and all the changes to a given component for a given synch request are stored in one change set. But it does associate that change set with a set of RTC tasks which represent each of the UCM activities that contributed to that change. And if the CQ synchronizer is in use, those RTC tasks are synchronized with the corresponding CQ record. Cheers, Geoff |
![]()
Geoff,
Thanks for the info!! That technote was very interesting! Wish I had seen that a couple of weeks ago :) We actually did get the CC connector working on our trial copy, and did a few experiments with it, and it worked. I never did try anything like deleting files, or moving files, or renaming files/directories -- does that synchronize across correctly as well? Like I've said on some of my other posts, this is an incredible product... You guys did an amazing job!! I'm still pushing for adoption in my org, and we're just working through "the wickets," like getting these connectors working. Next up -- the CQ connector and UCM :) Which leads me to my next question, which is really just a restatement of my last question on the previous post. Let's say I am working in RTC, but my org at the "top" is using CC/CQ with UCM integration. If I associate the correct RTC work items with a changeset, and then the synchronizer runs, will those checkins that get put into CC by the synchronizer be appropriately marked with the correct activity? (IE, I am asking about RTC -> CC; I think you answered CC -> RTC?) Regards, Mike |
![]()
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 07 '09, 2:56 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Mike,
Thanks for the kind words! (We think it turned out pretty well, but it's what you think that counts :-). WRT deleting files, moving files, renaming, yup, everything should work as you hope. In fact (to show off a bit :-), if you rmname a file in ClearCase, and sync it over, the file will be removed from the Jazz stream, but if you subsequently restore that file into the ClearCase stream, and sync, it will actually restore that original Jazz file (with all of its history) back into the Jazz stream. WRT the behavior from RTC -> CC, it's the same as the behavior from CC -> RTC, namely, only the latest versions from the RTC stream will be carried over (not the intermediate versions), but that when the sync is done, it will annotate the resulting UCM activity with the list of Jazz work items that contributed to the changes since the last sync. Cheers, Geoff micjohnson997 wrote: Geoff, |
![]() WRT the behavior from RTC -> CC, it's the same as the behavior from CC With regards to that statement, does it still play well if we have CC/CQ integration enabled for UCM? IE, activities are really just CQ records, which are themselves "sync'ed" to RTC work items? Thanks, Mike |
![]()
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 07 '09, 9:36 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Yes, if you are using CQ-enabled UCM, and the CQ synchronizer, then each
activity is CQ activity (linked to a CC activity), and that CQ activity is synchronized with an RTC work item (and that RTC work item is linked to the appropriate change-set created by the CC sync process). Cheers, Geoff micjohnson997 wrote: gmclemmwrote: |
![]()
Mike you might also want to take a look at the article "Setup ClearCase & ClearQuest Connectors in a ClearQuest-Enabled UCM Environment" at
http://jazz.net/library/article/30 It was written for the RTC 1.0 release, and it's in the form of a particular example, rather than generalized instructions. So some of the setup and UI details may be a bit different in RTC 2.0 (in particular, there is now a setup wizard for the CQ Connector that automates most of the previously manual stesp), but the latter part of the article should give you a feel for how synchronization will work once things are set up. |
![]() Yes, if you are using CQ-enabled UCM, and the CQ synchronizer, then each activity is CQ activity (linked to a CC activity), and that CQ activity is synchronized with an RTC work item (and that RTC work item is linked to the appropriate change-set created by the CC sync process). Geoff, after looking @ the article that jrvasta links to, I am not sure whether or not this is correct. Can you confirm? If I look at the article, it seems to state that when code is sync'ed from RTC to CC, then a *new* UCM activity is created that contains all of the code changes that need to move over. Then that UCM activity has some text inserted in its description that says "Synchronized Task: <work>". So it seems that the UCM link between the code in CC and the records in CQ is lost, because it doesn't really associate between the code->CQ record UCM activity, but from the code->some new UCM activity created expressly for checking in code in CC. (The activity title seems to be "Record created for ClearCase Connector.") Like jrvasta said, this is an old 1.0 article, so I am hoping that maybe this behavior has changed for 2.0? If I am reading it right, it seems like the whole point of the UCM integration (linking CQ records->code changes in CC) has been lost...? Thanks, Mike |
![]()
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 11 '09, 5:54 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
When you use the CC Synchronizer, it only brings over the current
(latest) configuration of the stream, not all of the intermediate versions that have been created since the last time you synced. There are a number of reasons for that, including: - performance ... bringing over all intermediate versions would be prohibitively expensive - scope ... you only sync selected trees ... that means that change sets would just be partial, namely the part of the change set that is in the trees you've selected to sync - versioning model incompatibility ... RTC SCM uses a different underlying versioning model than ClearCase for folder versions (CC folder versions know their immediage children names and elements ... RTC SCM folder versions only know their parent element). So you can't bring over folder versions in any reasonable way. So the net result is that there are not in general versions in ClearCase that you could associate with those change-sets from Jazz (or vice versa), so the best you can do is what is done today, i.e. annotate the *new* UCM activity created by the sync with the list of UCM activities associated with Jazz work items. Cheers, Geoff micjohnson997 wrote: gmclemmwrote: |
![]()
Geoff,
Thanks for the info! Below I describe what I think is happening, and I just want to make sure I understand what's going on before someone else asks me about this on our team: 1. Let's say that, as a dev, I am working on one particular work item/CQ record (because they are synced). And I check in, say, 5 files once a day for this work item. Then let's say I work it for 10 days. Let's also say for simplicity that I am the only one working in this RTC stream/CC sync'ed stream. Does this mean, at the end, that I would end up with 10 different UCM activities (one per day because that's the only time that the sync picks up anything)? And the 10 UCM activities would have the same 5 files in them, just in different states? So I think this means I cannot select the single UCM activity in CC (the one associated with the RTC work item) to see a single view of the code changes that make up that activity, right? (The code changes are scattered across the 10 different UCM activities that correspond to the 10 rounds of synchronization...?) 2. Now take the previous situation and reverse it. Let's say I have 10 devs working on a RTC stream/CC sync stream. They each check in 5 different files for 10 different work items/CQ records. Does this mean that for each "round" of synchronization there is always one UCM activity created, with 50 files in it, whose description contains the headlines for all 10 work items? This would mean, I think, that there's no traceability from the individual code changes back to the individual work items, right? Thanks, Mike |
![]()
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 12 '09, 10:48 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Comments interspersed below:
micjohnson997 wrote: Geoff, Yes, one new UCM activity for each sync (independent of how many files were changed in that VOB since the last sync). And the 10 UCM activities would have the same 5 In order to see the code changes made in a given activity, you have to follow the link to the repository in which those code changes were made. So we maintain full traceability via the link to the work item in the jazz repository, but you have to traverse that link to see the detailed information. 2. Now take the previous situation and reverse it. Let's say I have Same as above. The link back to the work items gives you full traceability ... but you have to use those links to get back to the repository with the change sets to see that detailed information. We also don't sync across all the related work items, all the plans containing those work items, all the baselines containing those change sets, etc. In each of those cases, you also have to traverse the link back to the original repository, in order to see that detailed information. But full traceability is maintained (via the cross-repository links). Cheers, Geoff |
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.