Can I use the same change set associated with different work items to deliver to different streams?
I attach the same change set to two work items, one for release X and the other for release Y and request review approvals on both work items.When work item X has its review approved, but Y is still pending, I am unable to deliver the change set from work item X to stream X because of the outstanding approval for work item Y (which will deliver to stream Y). Is this expected behaviour? I though the use of change sets was to provide a mechanism to deliver the same changes to multiple streams.
|
3 answers
Ralph Schoon (63.5k●3●36●46)
| answered Apr 18 '13, 4:44 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Rachel,
I am wondering how we do this. I'll ask 8-). One approach would be to associate the change set to the second work item only after the change has been successfully delivered. In this case you would have no issue. So the workflow would be like: 1. Develop a change 2. Deliver the approved change to a stream 3. Associate the change set to a new work item for the other stream (now the change set can't be delivered, but that does not matter because it is already in that other stream) 4. Accept the change into a workspace for the other stream (it is delivered, hence completed) 5. If necessary merge and add/modify/test code and associate the new changes to the same active work item. 6. Suspend and request for approval 7. After approval deliver. Another thought is using a patch that probably creates a new change set. Otherwise you can request an enhancement. I tried in 4.0.1 and 3.0.1.1. So this is no new behavior. I also think it would be tough to come up with a good implementation. You would either have to set the rule that there needs to be at least one work item with an approval associated to the change set. Or you would have to ignore work items not owned by the team that owns the stream. Or you would need an indicator for which stream an approval is. All that would make configuring the process (and understanding what happens) a lot harder, I think. Comments
Ralph Schoon
commented Apr 18 '13, 4:47 a.m.
| edited Apr 18 '13, 4:48 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Another thought I had was to have the streams owned by different teams and require a different type of approval for delivery in the the different team areas. That however would require to only use one work item, but different approvals on this one work items to work. Or you'd end up needing two different approvals on each work item.
Thanks - your suggestion above about only attaching the change set to the second work item after its been approved and delivered by the first, is currently how we're working around the problem this causes us - but that requires people to remember to go back to do the other work item at a later date .. hence people are mostly giving up with the using the same change set.
Thanks - your suggestion above about only attaching the change set to the second work item after its been approved and delivered by the first, is currently how we're working around the problem this causes us - but that requires people to remember to go back to do the other work item at a later date .. hence people are mostly giving up with the using the same change set. |
|
Ralph Schoon (63.5k●3●36●46)
| answered Apr 17 '13, 12:26 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Rachel, I just looked into the SDK and as far as I can tell, the code goes through all work items that are linked to the change set and throws an error if the approval can not be found. Now, I have not fully understood the code but I did not see anything that shows that the work items found are checked if they are owned by the process area that owns this stream. I can also not find anything in the configuration that would allow the operation to be configured to distinguish what work item to pick and which to ignore.
I then ran a simple test. I did a small change and assigned two work items to the change set. I tried to deliver ant I was told that both work items need that approval. Comments Thanks for the response Ralph. So I guess this is working as designed - but that means for our service project, we're unlikely to be able to use the same change set for both our latest service and the development stream for resolving APARs, which is a shame :o(
|
|
Thanks - your suggestion above about only attaching the change set to the second work item after its been approved and delivered by the first, is currently how we're working around the problem this causes us - but that requires people to remember to go back to do the other work item at a later date .. hence people are mostly giving up with the using the same change set. This has the unwelcome effect that should a problem be found with the original (or duplicate) change set, its not as easy to identify its the same change and needs to be pulled/corrected.
|
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.