It's all about the answers!

Ask a question

How is it possible to relate a work item to a stream.

Geoff Binns (30424) | asked Jan 29 '16, 7:55 a.m.

Work Items can only be related to an iteration and change sets can only be related to a work item.

It would be useful to be able to target a work item to a stream to ensure the stream has had the correct work items applied.

Is there any way of ensuring the correctness of a Work Item being applied to multiple streams.

Accepted answer

permanent link
Melissa Kivisto (2871021) | answered Feb 01 '16, 6:08 a.m.
 Hi Geoff,

This would be a manual process (at least to start, but I'm sure you could write some surrounding code with the API to help automate), but you could try adding approvals (maybe of type verifcation?) for each stream you want the change in, and then approve them only once it's confirmed the change set(s) on the work item have been delivered to each of those streams.  
Geoff Binns selected this answer as the correct answer

2 other answers

permanent link
Ralph Schoon (63.1k33646) | answered Jan 29 '16, 8:06 a.m.

I think there is some misconception on your end, or some misunderstanding on my.

A Stream is a volatile object, it can be created and deleted, however the change sets will stay, and the work items as well. The change set can be in many streams as well.

There is no means in the RTC Work Item component to represent a stream as an attribute. A stream, of course, has a URL and you could link that to a work item, however this would not be easy to use for anyone.

So I am not sure what you want to achieve in the question above.

It is possible to use the Locate change Sets functionality in the Eclipse client Search>Jazz Source Control>Locate change Sets to find out if a change set is in a particular stream or not, you can use work items to select the change sets associated to it for this as well.

Geoff Binns commented Jan 29 '16, 8:34 a.m.

I think I am raising a change management issue. The use case is, a change needs to be applied to a component in multiple streams each representing different versions (or what some may refer to as branches).

There doesn't seem to be a controlled way in the work item to tell the developer which stream(s) are to have the change applied to. The developer may do the change using one or more flow targets to the streams but there is no guarantee that a stream did not get missed. Moreover, I cannot see how anyone can check except by checking that a change set had been applied to all the required streams.

Ralph Schoon commented Feb 01 '16, 3:22 a.m.

We have a work item attribute type "Item" that can reflect some items e.g. a component, but not a stream. That was my first Idea. If you could make it to select a stream it would be possible to add operational behavior to check if the target stream is the intended one as well.

I agree, it would be a good idea to raise an enhancement for that. I have seen this kind of question before.

permanent link
Geoffrey Clemm (30.1k33035) | answered Jan 29 '16, 5:51 p.m.
The assignment to each work item of where it should be delivered is commonly used in branch-based systems, where the relationships between branches are largely fixed, and each change is local to a single branch until it is "merged" to another branch.   In RTC, where you are free to modify the relationship between streams at will, and where changes are shared between many streams, this technique is not very effective, because every time you modify your stream system, you'd have to go and update all the work item assignments.   Instead, best practice is to define flow relationships between your streams, so that a given change is first delivered to a single stream, and then stream-to-stream flows take that change automatically to the other streams it should be applied to.   Then the locate-change-set functionality that Ralph mentions can be used to verify changes have flowed as intended.   This in particular is best practice for flowing changes from one release to all the subsequent releases.

There are some special cases where one would use other techniques (and you may have one of those special cases).  If you could describe why the stream-to-stream flow wouldn't work for your case, we could suggest some other alternatives.

Geoff Binns commented Feb 01 '16, 3:26 a.m.

Hi Geoffrey,

Thanks for your time and responses.

We are rolling-out RTC in our environment so I am trying to consider every use case we use for our developments. I am thinking of where the stream-to-stream flow may not work for us. Where we may be using Product Line Engineering or have multiple variants/releases being developed in parallel. A change may be needed to be applied to a specific stream but not others. So there is no fixed flow relationship between streams. Each developer may need to work on different variants in different streams. So from the work item it needs to be known which variant/stream the change has to be applied.

If this is a case where why the stream-to-stream flow wouldn't work I'd be grateful for any alternative suggestions.

Geoffrey Clemm commented Feb 01 '16, 3:26 p.m.

Yes, if you are cherry-picking to which variants a given work item should be delivered, then I agree with Melissa's suggestion of using work item Approvals.

Your answer

Register or to post 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.