Parallel development

When multiple teams are working in the same application rulesets, coordinating changes across teams is a challenge. When development teams configure an application in parallel, rule changes might result in conflicts. Resolving conflicts disrupts the overall project and may delay time to delivery.

Pega Platform™ uses branches to help teams manage parallel development in distributed environments. A branch is a container for rulesets with records that are undergoing rapid change and development. The rulesets associated with a branch are called branch rulesets.

A branch ruleset:

• Is based on (branched from) another ruleset
• Contains rules that are in active development in the associated branch

In Pega, you create a branch for each team. These branches allow each team to create and update rules without impacting other teams.

The following scenario describes how branches allow multiple teams to make rule update changes in parallel.

Team Alpha and Team Beta are developing an HR Onboarding application. Team Alpha is assigned to develop a new UI feature. Team Beta is assigned to work on candidate profile information. While each team works independently, both features involve changes to rules in the same rulesets: HR, HRApps, and HRAppsInt.

Using branches and branch rulesets, each team creates its own development branch. When the rule updates are complete, each team resolves conflicts the system detects between the branch rules and other instances of the rules. After the team resolves rule conflicts, the system merges the updated branch rules into the original application.

Branches allow each team to work within an isolated space (the branch) without affecting functionality other teams are developing. They are especially useful on large development projects, where multiple teams work simultaneously on the rules in an application. Each team works on their changes independently. All members of a team can see each other's work, while isolating the development changes from other teams. Changes do not affect other teams until the changes are stable, conflicts are resolved, and approval is granted to make the changes available to all development teams.