How to automatically deliver changesets by skipping the files which have conflict
shubhada todankar (11●1)
| asked May 02 '19, 1:40 p.m.
retagged May 06 '19, 3:24 p.m. by Ken Tessier (841●1●7) We are using a solution mentioned in the article https://jazz.net/library/article/529/ under section Delivering Change Sets Automatically Between Streams to sync up development stream from production stream.
|
3 answers
Hi Shubhada. The problem you will encounter is that if there is a conflict, and there are change sets stacked up for a source member, that conflict must be resolved before any others will be able to be delivered, otherwise, you would get a gap.
I'm guessing you are seeing this on specific components, where if there is a conflict on a component, it will stack up change sets until you resolve them.
A long term strategy might be to break the components into smaller components (knowing your environment, I'd say that's going to be hard and a long term goal at best).
Another idea is if you have copybooks that are used by many members, you could separate those into their own component, and nest them under the components that would use them. Look at this article on subcomponents: https://www.ibm.com/support/knowledgecenter/SSYMRC_6.0.6/com.ibm.team.scm.doc/topics/t_component_add_remove.html
Lastly, you could also split streams into more up streams (i.e. indigo and navy flow into the blue stream). That may help developers work a bit more independently and allow team leads to focus on just the blue stream for conflict resolutions.
|
Ralph Schoon (63.1k●3●36●46)
| answered May 08 '19, 5:19 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER edited May 08 '19, 5:20 a.m. The only way to solve this is to make sure there are no conflicts and gaps introduced.
Conflicts can only avoided when only one person works on a file. Otherwise you have to accept and merge them.
Gaps can be avoided by using a preconditon for checkin.
Gaps are introduced if you change the same file in different changes sets together with other files.
E.g. File f1, f2, f3.
Change CS1: F1, F2
Change CS2: F1, F3
You can not deliver CS2 without delivering CS1 before.
A custom checkin precondition can prevent checking in changes to multiple files into the same change set and help avoiding this situation. Customers have implemented this kind of stuff to make cherry picking during integration possible.
|
|
Ralph said it better than me.
Regarding the preconditions, I wrote a blog article on the ones that should be used for RTC on z/OS. This may help in your situation, especially the one on Restrict Change Set Size:
|
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.