Relating two Jazz Repositories
We would like to set up our own separate Jazz Repository for System Test tasks, process, documents, etc., but have it somehow related to another Jazz Repository which contains the defects which we write, developers fix, and we verify. Is it currently possible to relate two repositories, and if so, where would I find details?
Thanks so much -- Carol Ulbricht |
13 answers
srich@us.ibm-dot-com.no-spam.invalid (srich) wrote in news:f82pmh$fu1$1
@localhost.localdomain: Just curious, what were you trying to achieve with separate Scott, in our scenario, we would want to use our internal server to discuss work items locally (in our company). Some of our work item may be dependant from a Jazz.net work items. So we would like to be notified when a Jazz.net work item is modified. Let me know if you want me to elaborate -- Christophe Elek Serviceability Architect IBM Software Group - Rational |
There's currently no way to reference across repositories. If you want to be able to create links between, for example, a system test testcase document and a bug it uncovered, you would need these to live in the same Jazz repository and Project Area today.
A single repository, with one common Project Area, with one or more Team Areas for System Test and one or more other component/release teams would be the way we support this today. One reason why we require this structure is that it forces the test and development halves of the project to agree on the basic process the Project is going to use, then they can each customize it to their own usage within their Team Areas. Just curious, what were you trying to achieve with separate repositories? Scott Rich |
|
Scott said
Just curious, what were you trying to achieve with separate repositories? Hi Scott, We will have separate artifacts, processes, schedule, etc. and a lot of internal tasks of our own related to our process and our test environments that might be a distraction on jazz.net, so it was suggested that we should have our own self-hosted space. I was trying to figure out, if we did that, how would we maintain the collaboration we need for agile development, and not just throw defects over the wall? So perhaps you could say I backed into the question from the wrong direction. I'm wondering what your thoughts are on the relationship of Development & System Test. Do you see them as separate Team Areas and Development Lines in the same Project Area due to the difference in schedule? Wouldn't the members of System Test have to be committers on jazzdev to make that work? Beyond that, though, are you planning to support federated repositories some day? Isn't there a limit to scalability without it? Since I am thinking specifically in the space where small teams and large enterprises come together around loosely coupled components that may share a common build, what if many of the component teams were ClearCase users, but more than one team used Jazz? Could the connectors of the future deal with that? Now take it the next step, what if there were many components on Jazz and none on ClearCase? What is the vision? Thanks, Carol |
Christophe,
You can always add yourself as a subscriber to the core Jazz.net work item and you will get an email whenever it is updated. However, I agree with you and Carol that there are cases (at least for now) when it makes sense to maintain separate Jazz repositories and provide some connector like functionality between them. Although Jazz is meant to be an Enterprise repository, in real life (e.g. in the case of virtual corporations) it makes sense to keep separate repositories for separate needs and define very clear synchronization links between them. Otherwise, we'd need a very strong Access Control mechanism in place that prevents team members not belonging to the team from browsing content in the secure team area. In some cases, full transparency is just not as appropriate as for other teams. Also, work items would probably need to be classified with secured categories to prevent those who do not have permission to view those discussions from finding out anything they're not supposed to. Not sure if you view the above as resistance to openness on our part or a real concern that may be surfaced by customers in the future. |
|
aaakilov@us-dot-ibm-dot-com.no-spam-invalid wrote in
news:f85afo$iim$1@localhost.localdomain: Not sure if you view the above as resistance to openness on our part Howdy :) I agree it is not a Simple Problem... I think some eclipse commiter call that RFP :) Really Fun Problem :) So... :) Should we open an RFE in jazz.net ? -- Christophe Elek Serviceability Architect IBM Software Group - Rational |
Geoffrey Clemm (30.1k●3●30●35)
| answered Jul 30 '07, 2:39 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The SCM Connector and Item Connector components (that implement the CC
Connector and CQ Connector, respectively) are written in a generic fashion that architecturally would allow a Jazz to Jazz connection. So if you believe SCM/Item Connector semantics would be valuable/desirable between two Jazz repositories, feel free to file an RFE workitem in the Connector category (please include information about what kind of information you want to be sync'ed over). Cheers, Geoff aaakilov@us-dot-ibm-dot-com.no-spam-invalid wrote: However, I agree with you and Carol that there are cases (at least for |
|
For SVT, I think being able to synchronize some subset of work items would be first priority. For example if we have a separate repository for Test, we would want to synch the defects we write, and also selected defects written by customers or developers, with the developers' repository. We would want to receive any attachments to those defects. However, we would want to be able to make private associations between those defects and other Work Items in our repository that are not synched or visible in the developer's repository.
Second priority would be synching a (small) portion of the SCM. For example it would be good if testers could on occasionn deliver an entire workspace to developers for debugging, and developers could deliver patches to testers, to make sure a proposed fix works in our environment. In the case of development by virtual teams spanning multiple organizations, delivering a component to both a development repository and an integration repository would probably be more important than work items. Third priority would be including events from two repositories in the same Team Central. Does that agree with what the rest of you think could be done/would be useful? Carol |
|
Geoffrey Clemm <geoffrey.clemm@us.ibm.com> wrote in news:f8lb96$h3f$1
@localhost.localdomain: feel free to file an RFE workitem in the Connector category Anyone sees the Connector Category in Jazz.net ? I thought we had an Incubator category, but I cannot see it anymore :( -- Christophe Elek Serviceability Architect IBM Software Group - Rational |
|
Christophe Elek <Christophe.Elek@gmail.com> wrote in
news:Xns997E62C0E7B79celekcaibmcom@199.246.40.53: Anyone sees the Connector Category in Jazz.net ? As per John and to follow on the same thread: "The category for "item interoperation" (e.g. the CQ Connector) is actually named "Interop", and the category for "SCM interoperation" (e.g. the CC Connector) is "Interop SCM". John" -- Christophe Elek Serviceability Architect IBM Software Group - Rational |
|
Geoffrey Clemm <geoffrey.clemm@us.ibm.com> wrote in news:f8lb96$h3f$1
@localhost.localdomain: feel free to file an Opened Enhancement 28113 https://jazz.net/jazz/web/projects/Jazz%20Project#perspective=Work% 20Items&action=viewWorkItem&id=28113 -- Christophe Elek Serviceability Architect IBM Software Group - Rational |
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.