It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,788
×11,927
×69
×60
×38

question asked: Dec 16 '15, 5:17 p.m.
question was seen: 3,123 times
last updated: Dec 29 '15, 9:43 a.m.

Related questions

FAQ - How this Forum works

Urgent question on RTC EE promotion handling of two developers making changes in the same source member

0
Alex Akilov (121●17●24) | asked Dec 16 '15, 5:17 p.m.
edited Dec 16 '15, 5:24 p.m.
Hey guys,
Need a quick answer.

We are trying to get promotions to work and are observing the following behavior, which we’re not happy with.  Perhaps we’re doing something wrong and you can quickly set us straight.  We’ve tried this on RTC 5.0.2 but I haven’t seen anything in the 6.0.1 N&N that indicates to me that the behavior we observed would change with the latest enhancements.

Scenario:
Dev1 modifies cbl1 and cpy1
Dev2 modifies cbl1 and cpy1

Dev1 delivers his changes to the Dev stream and they get built
Dev2 accepts Dev1’s changes and delivers his changes to the Dev stream and they get built.  Note that the load module now contains Dev1 and Dev2’s changes.

Dev1 wants to promote his work item and gets all of the needed approvals.
Dev2 has not gone through the approval process for his changes yet.

A promotion is attempted.  Dev1’s work item is picked up to be promoted and the promotion fails, saying that cpy1 is not in the proper state in the target stream. 

Dev2 decouples his cpy1 change and associates it with a separate work item and gets it approved.  Note that all copybook changes are considered non-impacting in our shop since we do not want to rebuild the world when a copybook changes (we usually append to the end of a data structure by reusing some reserved space).

The promotion is attempted again for all approved work items (including the new cpy1 work item) and surprisingly, the load module (which includes Dev2’s unapproved change to cbl1) is allowed to be promoted!

This is a problem for us.  Are we doing something wrong?

2 answers

Most liked answers|Newest answers|Oldest answers ↑

0
permanent link
Hung Lam (291●19●15) | answered Dec 17 '15, 12:25 p.m.
JAZZ DEVELOPER
Hi Alex,
Are you expecting Dev2 to fail with the same validation error message as seen by Dev1 (ie:  the cpy1 is not in the right state in the target stream)?  OR  you expect the promotion to fail because Dev2's work item does not have all of the right approvals?  Thanks.
Comments
Alex Akilov commented Dec 18 '15, 10:35 a.m. | edited Dec 18 '15, 10:48 a.m.

 Hung,


I was expecting the first.  Why are only copybooks flagged as not being in the right state?  I think any change set that was included in the build outputs that isn't in the work items being promoted should be reported as missing.
Note that it's not enough to fail with an error but there needs to be a way to resolve the problem.  For example, if Dev2's changes need to be backed out so that Dev1 can continue with promoting his changes, how can that be accomplished?  Can Dev1 deliver a reversal change set for Dev2's changes and rebuild the load module and then be allowed to promote without requiring Dev2's work item (since the latter isn't approved)?  This means that the analysis of what outputs should be promoted should be based on which change sets were included in the outputs and do the work items being promoted include those change sets  (even if the latter change sets were in a different work item when the build was performed).  It should be possible to reassociate a different (approved) work item with the faulty change set along with its reversal so that it can be promoted.

0
permanent link
James Cole (95●3●26●30) | answered Dec 24 '15, 7:51 a.m.
Hi Alex, 

Which version of RTC are you using?

Many Thanks 

James
Comments
Alex Akilov commented Dec 29 '15, 9:43 a.m. | edited Dec 29 '15, 9:43 a.m.

 James, I indicated in my post that we're on 5.0.2

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.