When you use branches, different development teams can work without interfering with changes that other teams make in an application, even if multiple teams share one base ruleset. For example, Team A can develop service-level agreements for a case type while Team B fixes UI bugs in the application. When you provide separate branches for both teams, you minimize the risk of errors and work overwrites that might arise when both teams work on the same ruleset simultaneously.
To organize rules better during your development process, you can categorize rules into branch rulesets. Branch rulesets have the following characteristics:
- Branch rulesets are branched from rulesets in your application.
- Branch rulesets contain rules that are in active development in an associated branch.
- Branch rulesets have a naming convention that includes a ruleset ID, the word Branch, and a branch name, for example, SLAS_Branch_TeamABranch, where SLAS is a ruleset ID, Branch indicates a branch ruleset, and TeamABranch is a branch name.
Branching is especially useful in large development projects when multiple teams work simultaneously on the rules in an application, and members of one team view each others work, but isolate their development changes from other teams. Consequently, rule changes that one team makes do not affect the other teams until the changes are stable, conflicts are resolved, and the approval is granted to make the new improvements available to the entire development project team.
Branched development includes the following main tasks:
- You create a development application that your team can use to develop new features. You
create a development application by copying an existing application to ensure that the
names of classes and rulesets remain unchanged.
For more information, see Creating a development application.
- You add development branches to the development application. Teams use branches to
develop features independently.
For more information, see Creating branches.
- As a best practice, you create a branch review to ensure that rules in your branches are
guardrail-compliant and meet your business objectives.
For more information, see Branch reviews.
- You make new features available in your application by merging changes from branches
into a target ruleset. You now can resolve conflicts and address warnings that might arise
among different branched versions of the same ruleset.
For more information, see Merging branches into target rulesets.
Branches and unlocked rulesets
An alternative to branched development is working in unlocked rulesets. Unlocked rulesets are suitable for projects that typically involve one team, and team members immediately need to view changes that any team members make. When a developer saves a change in an unlocked ruleset, the change immediately affects the work of other developers on that application.
During branched application development, a change that a developer makes in a branch ruleset affects the work that other developers do on the same development application only after merging changes into a target ruleset.