Table of Contents

Branches and branch rulesets


Only available versions of this content are shown in the dropdown

Branches help you manage work in development environments in which multiple teams contribute to a single application. You use branches to develop software simultaneously in a version-controlled environment. For example, a team can develop a feature in one branch while another team develops another feature in a different branch, even if the teams share the same rulesets.

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:

  1. 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.

  2. You add development branches to the development application. Teams use branches to develop features independently.

    For more information, see Adding development branches to your application.

  3. 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.

  4. 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.

The following figure shows a sample scenario in which multiple development teams create service-level agreements (SLAs) and resolve UI bugs in a Loan Requests application. An administrator creates two development applications: one for the UI teams and one for the SLAs teams. In each application, the administrator creates two branches that contain branch rulesets. As a result, two teams can resolve UI bugs and two teams can develop SLA rules without affecting another team. After the development is complete, the administrator first reviews and then merges branches into target rulesets. As a result, the Loan Requests application includes new features from the simultaneous work of four development teams.
Branched development
A diagram that shows a schema of branched development in which four teams work
            simultaneously on one application

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.

Did you find this content helpful?

100% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.