Looking for some help in understanding scenario to use branching. Why should I use branching if I am already using below approach for parallel development in a multiple team project.
For example, say we have three teams A,B and C working in three modules. If I allocate ruleset from range of 01-01-01 to 01-01-05 to team A, 01-01-06 to 01-01-10 to team B and 01-01-11 to 01-01-15 to team C and they use rulesets in their allocated range for build, they can still do parallel development without any issue, right?
Then why we should not take this approach instead of branching for parallel development?
***Edited by Moderator: Pooja Gadige to add platform capability tag***
The way to allocate different ruleset to different team doesn't exactly serves the idea of parallel development.
For example, Say team A,B,C are using the same rule for some processing. Once the changes are done by all 3 teams, do you have any way to merge this for allocated ruleset? Because each team changes are different from each other and by your logic, only team C logic will be displayed and not all 3 teams.
This is possible with branching. Team can work on different or same set of rules in parallel and then merge their changes right before the code implementation.
@PrakashDeep Thanks for your response. Yes you are correct in saying that branching can identify any rule conflict which is difficult to identify with my approach. But is there any other reason my approach is not good enough? I am planning to move to Branching for parallel development but just trying to understand the maximum benefit I can get from branching over my current approach.
Parallel development concept comes into the picture if multiple teams/developers are working on same set of rules. If your approach is followed and a same rule is changed by team A and C. Only the rule in C gets picked always as it is in highest ruleset version. If branching approach is used the same rule will be 2 different branches(team A and team C branches).And while merging the branches, the merge conflict can be resolved and both the team changes will be available post merge
@HariPriyaY Thanks for your response. Yes you are correct in saying that branching can identify any rule conflict which is difficult to identify with my approach. But is there any other reason my approach is not good enough? I am planning to move to Branching for parallel development but just trying to understand the maximum benefit I can get from branching over my current approach.
There might be many advantage of using branching. Few ones that i am aware of :
1. There is no dependency among team in terms code deployment. One team might be ready with their code and want to move ahead. It is possible with branching. later when other team decide to move their code, they can merge the changes before deployment and resolve any conflict.
2. Secondly what me or hari mentioned in his reply, this enables teams to parallel develop and work on same set of rules without having to worry about the parallel set of changes from other team.
3. One branch can be associated with multiple ruleset. For e.g. if you have an implementation layer with Ruleset A and a framework layer with Ruleset B, when you save the changes in your branch , the respective branch ruleset be available and at the time of merge, it can be merged with respective rulesets.
These are few points that i have seen. There might be other benefits also. You can certainly browser through PDN
@Bipul Singh , The primary issue is there's a reason for the Guardrail demanding no more than 1 open ruleset. Attempting any other practice will result in eventual rule resolution issues. Developers will step on each other's toes, and worse yet you'll run into regression issues trying to manage releases.
After you "bite the bullet" and get your team ingrained with the right habits, branching + DevOps tooling is much, much easier than any alternative. Trust the force, Luke.