Question
Mphasis
US
Last activity: 9 Aug 2016 12:29 EDT
What are the disadvantages of branch rulesets?
Hi everyone,
I know branch rulesets are pretty useful for parallel development and in my current project, I extensively use the same as well. However, I was wondering if any of you saw any issues with branch rulesets? Like any particular disadvantage that you can think of in case you are using branch rulesets? Maybe, some issues that you have faced while working with branch rulesets?
Thanks.
Accepted Solution
Pegasystems Inc.
US
Hello,
To Arijit's point, we do support almost all scenarios required for developing in branch rulesets with a few exceptions.
- One of which was pointed out by Murali. Access groups on node level data pages are not supported.
- Libraries, Rule-Methods, System Settings as these do not have a ruleset version associated with it. With Classes, you can create new classes in a branch and then merge them to your base ruleset, but you cannot Check out to branch an existing class and update it again because it is does not have a version.
- Ruleset restriction added on classes in the branch need to be manually modified after the merge. The class rule form does not allow specifying the base ruleset name as it is a prerequisite for the branch ruleset.
To Eric's point, currently we do not have any "smart" detection at the rule level itself. The current compare uses the old rule compare UI to display the conflicts and is not the best but is what we have today. We do have smarter conflict detection across rulesets and ruleset versions, where it will identify conflicts across branches merged together using multi branch merge, it will preemptively warn you on conflicts with other branches across the system etc.
To Murali's point, the false conflicts that had happened were due to a specific issue (if you save as a rule from one branch to another and then perform the merge, it will show as conflict). This issue has been fixed in 7.2.1
Hello,
To Arijit's point, we do support almost all scenarios required for developing in branch rulesets with a few exceptions.
- One of which was pointed out by Murali. Access groups on node level data pages are not supported.
- Libraries, Rule-Methods, System Settings as these do not have a ruleset version associated with it. With Classes, you can create new classes in a branch and then merge them to your base ruleset, but you cannot Check out to branch an existing class and update it again because it is does not have a version.
- Ruleset restriction added on classes in the branch need to be manually modified after the merge. The class rule form does not allow specifying the base ruleset name as it is a prerequisite for the branch ruleset.
To Eric's point, currently we do not have any "smart" detection at the rule level itself. The current compare uses the old rule compare UI to display the conflicts and is not the best but is what we have today. We do have smarter conflict detection across rulesets and ruleset versions, where it will identify conflicts across branches merged together using multi branch merge, it will preemptively warn you on conflicts with other branches across the system etc.
To Murali's point, the false conflicts that had happened were due to a specific issue (if you save as a rule from one branch to another and then perform the merge, it will show as conflict). This issue has been fixed in 7.2.1
We do you have refinement stories in our backlog to handle scenarios 1 and 3 mentioned above. We also have a enhancements to rule compare UI and its integration with the Merge Wizard conflict detection in our backlog.
Given that, we would love more feedback from you so that we can support any additional use cases or enhancements that will make working in branches more seamless.
Thanks
Saurabh
Infosys
AU
We faced issues while working with Agents and Data Pages in branches. As these rules needs access group to be mentioned in rule form, not sure what's the best way to tackle these when multiple teams are working on separate branches?
In one scenario we have multiple teams having their own branches, so have to go for separate access groups which is different from trunk application. Due to this we have to change the access group name in Agent and Data Page rules in branch ruleset. But these rules needs to be skipped during merging (as the only change we made is access group). We have to remember this and manually delete these rules from branch just before merging!!! Not sure if better alternatives exist.
Another minor issue I faced is with false conflicts/warnings while merging.
Let us know if you also see any issues/challenges with branches.
Murali...
Pegasystems
US
How smart is the merging ? One test I'd be interested in trying is, suppose you and I both work on the same activity rule. I insert a step at the beginning. You insert a step at the end. Will the merge think we conflicted with each other ? Or will it think we made non-interfering changes and quietly merge both in ? Or suppose we both insert a step at the beginning and one at the end. During the merge, how easy is it to convey "take HIS step at the beginning and MINE at the end". /Eric
Infosys
AU
Merging (branch merging) is not that smart (my opinion!). As far as I know, it just compares the update/create date time values of the rules to determine if there are conflicts or not. Existing Compare feature in merge wizard might not be of much help as it just shows the all the differences by property wise.
In case of conflicts, user has to resolve the conflict outside the merge wizard, by manually inspecting rules in trunk and in branch and then making changes in branch version. Once conflict is resolved, user needs to tick a checkbox in merge wizard confirming that conflict has been resolved.
Murali...
Accepted Solution
Pegasystems Inc.
US
Hello,
To Arijit's point, we do support almost all scenarios required for developing in branch rulesets with a few exceptions.
- One of which was pointed out by Murali. Access groups on node level data pages are not supported.
- Libraries, Rule-Methods, System Settings as these do not have a ruleset version associated with it. With Classes, you can create new classes in a branch and then merge them to your base ruleset, but you cannot Check out to branch an existing class and update it again because it is does not have a version.
- Ruleset restriction added on classes in the branch need to be manually modified after the merge. The class rule form does not allow specifying the base ruleset name as it is a prerequisite for the branch ruleset.
To Eric's point, currently we do not have any "smart" detection at the rule level itself. The current compare uses the old rule compare UI to display the conflicts and is not the best but is what we have today. We do have smarter conflict detection across rulesets and ruleset versions, where it will identify conflicts across branches merged together using multi branch merge, it will preemptively warn you on conflicts with other branches across the system etc.
To Murali's point, the false conflicts that had happened were due to a specific issue (if you save as a rule from one branch to another and then perform the merge, it will show as conflict). This issue has been fixed in 7.2.1
Hello,
To Arijit's point, we do support almost all scenarios required for developing in branch rulesets with a few exceptions.
- One of which was pointed out by Murali. Access groups on node level data pages are not supported.
- Libraries, Rule-Methods, System Settings as these do not have a ruleset version associated with it. With Classes, you can create new classes in a branch and then merge them to your base ruleset, but you cannot Check out to branch an existing class and update it again because it is does not have a version.
- Ruleset restriction added on classes in the branch need to be manually modified after the merge. The class rule form does not allow specifying the base ruleset name as it is a prerequisite for the branch ruleset.
To Eric's point, currently we do not have any "smart" detection at the rule level itself. The current compare uses the old rule compare UI to display the conflicts and is not the best but is what we have today. We do have smarter conflict detection across rulesets and ruleset versions, where it will identify conflicts across branches merged together using multi branch merge, it will preemptively warn you on conflicts with other branches across the system etc.
To Murali's point, the false conflicts that had happened were due to a specific issue (if you save as a rule from one branch to another and then perform the merge, it will show as conflict). This issue has been fixed in 7.2.1
We do you have refinement stories in our backlog to handle scenarios 1 and 3 mentioned above. We also have a enhancements to rule compare UI and its integration with the Merge Wizard conflict detection in our backlog.
Given that, we would love more feedback from you so that we can support any additional use cases or enhancements that will make working in branches more seamless.
Thanks
Saurabh
Areteans
IN
I know this topic is bit old, but has anyone faced any caching issues due to extensive branch ruleset usage. We have almost 15-20 branch rulesets as all the teams are working in parallel developement. I don't have a reason to justify this but just curious to know if there is a possiblity.