Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Branches and branch rulesets

Updated on November 15, 2021

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.

For example: 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.

For relevant training materials, see the Team application development module on Pega Academy

Have a question? Get answers now.

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

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us