What is the best strategy to setup streams where we need to roll back major change sets?
Lets see if I can explain this clearly enough. One of my clients currently has their streams setup in a format that looks something like below:
The development for version 13 starts with creating development streams for the different dev teams based on whatever is in production.
The dev teams deliver to their streams but also deliver right away to the integration stream.
The integration stream is used to build and deploy onto the dev & test environments for ongoing testing activities. (not shown in the diagram above)
They also start development on the next version (14) before 13 goes to production but use whatever is in the 13 Integration stream as a starting point of 14.
- This is where things get a little complicated. Sometimes part of what's in 13, for example everything in 13.1.02, does not make it to production and needs to be rolled out of the integration stream.
- This causes a couple of issues, right now they are deleting the 13.1 integration stream and creating a new 13.1 integration stream based on only the development streams that will make it to production. When they do this, they are seeing issues with change sets in 14 that have parent child relationships with change sets that didn't make it to the new 13.1 integration (and prod)
They also don't want to start 14 with the code that is in production (version 12) as there are major changes in 13 that are needed for release 14.
So the real question is, what is the best way to setup the streams so if changes from one of the development streams need to backed out it can be done easily without affecting the streams that are further down stream?
Thanks!
Saurabh
|
One answer
Did you want to remove the change sets completely? That would be an issue if there are change sets that build on top of the ones you want to remove. It seems you've figured out a way to get rid of them in your 13.1 Integration stream but have issues with getting them out of the 14.1 Integration stream.
It may be easier to reverse the change set at this point. It will create a change set that takes the changes out and you can deliver it to your 13.1 and 14.1 streams. This will be much easier to deal with but you'll have those change sets in the stream that added something along with the change sets that take it out. This would also mean that you don't have to recreate the 13.1 stream or heavily reconfiguring it with the changes you want. You'll just deliver change sets that reverses what was done.
Currently, there wouldn't be a way of accept just the change sets that you want if you don't want other change sets that it builds on. You would need gap support for that (https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/244998).
Comments Tim - what is the best way to revert a large number of change-sets from a stream? So far we have not been successful in reverting change-sets from an Integrated stream (i.e. 13.1) without much difficulty. We would have to revert hundreds of change-sets (coming from the original stream i.e. 13.1.01). We would also have to deal with merge change-sets in 13.1 stream as 13.1.01, 13.1.02 and 13.1.03 are likely to modify many common components. There really isn't another way to discard or reverse the change sets. You may want to take the approach in the original question to recreate the stream with the changes that you want. If you're been creating baselines before delivering changes, you can revert to that baseline where the unwanted changes don't exist. Then the changes you want delivered can be redelivered to the stream. It will likely require remerging but might be easier than trying to select all the changes you don't want so you can reverse them.
|
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.