Multiple stream synchronization on removal of change set
mark byrd (147●1●23●30)
| asked Nov 27 '13, 2:18 p.m.
retagged Dec 16 '13, 1:15 p.m. by David Lafreniere (4.8k●7)
Situation ...
* There are three streams … development, qa, and production.
* The usual procedure is for a developer to start by populating a workspace from the production stream.
* Depending on what the developer intends to do (join dev in progress, join qa in progress, or fix prod), the workspace can have its flow target changed to the other streams, to accept any change sets needed for the task at hand.
* The developer then creates change sets in the workspace.
* Before a developer can deliver a change set from the workspace to the dev stream, the workspace must accept change sets from the qa and production streams that have items in common with the one being delivered.
* Before a developer can deliver a change set from the workspace to the qa stream, the workspace must accept change sets from the production stream that have items in common with the one being delivered.
* Before a developer can deliver a change set from the workspace to the prod stream, the workspace must accept change sets from the production stream that have items in common with the one being delivered.
Issue ...
* As long as the task is proceeding normally, an “accounting style” “no “erasures” approach can be used. A bad change set is repaired by a correcting or reversing change set. All change sets, bad and correcting, proceed forward.
* But what about a delivered change set that needs to be eliminated, because the task is being abandoned, or the change set was delivered to the wrong stream?
* Using references https://jazz.net/forum/questions/81423/how-to-roll-back-remove-delivered-change-sets-in-rtc , and https://jazz.net/library/article/126#How_do_I_remove_a_change_set_fro … two approaches are possible.
* 1) “To remove a change set from a stream you can create a new change set that reverses it. To reverse a change set, the changes made in the change set are first undone. Then the reversing changes are checked into a change set that can be delivered to the stream. “
* 2) “You can also discard a change set from the stream by replacing the component’s configuration with a baseline that does not contain the change set. However, when a change set is discarded from a stream in this manner, it will appear as an outgoing change set for anyone who has already accepted it. It will also cause problems for anyone who has since built on top of that change set. “
* Approach #1 is in keeping with the “accounting style” “no erasures” approach. Unfortunately, this means delivering the abandoned change set, and its reversing change set, to all streams. Since the net result is no change, delivery to a stream that never had the original change set seems to be overkill.
* Approach #2 abandons the “accounting style” “no erasures” approach, but (as noted) introduces other problems.
Question ...
* Am I missing something that would allow, in a multiple stream environment such as our, “undelivery” of a change set to a stream without all the extra overhead to keep streams in sync?
|
One answer
Geoffrey Clemm (30.1k●3●30●35)
| answered Nov 27 '13, 3:55 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Approach #1 is the only safe approach for your environment. The only time it makes sense to use "replace" to back out of a change is if:
- you are just backing out of it temporarily, and want it to flow back in at some later time, or - the change set to be backed out has not been delivered to any other streams, and if that change set has been accepted into any workspaces, you can depend on the owners of those workspaces to know to discard that outgoing change, and not to re-deliver it. In any other scenario, you need to create the "reverse" change set, so that it can flow to all the appropriate streams. Note: I haven't had a chance to experiment with the new "rebase" functionality in 4.0.5, to see if it provides an alternative approach for this scenario. If someone wants to comment on that, please do so. |
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.