Parallel development

Pega Platform™ uses branches to help teams manage parallel development in distributed environments. A branch is a container for rulesets with records that undergo 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.

Branches are beneficial for both large and small-scale development projects, where single or multiple teams work simultaneously on the rules in an application. For example, in a single-team scenario, three members may work on a feature while two other members work on another feature without concern for interfering with each other's development. In a multiple-team scenario, branches help one team simultaneously work on the rules in an application without concern for overwriting work from another team.

Branches also benefit feature development when the time to completion differs between features. For example, if two features are being developed simultaneously but the first feature is completed before the second, branches help ensure that teams do not need to wait until both features are complete. Since the second feature is in an unstable state and its code is directly in your main ruleset, developing in a branch specific to the first feature allows application development to continue despite continuing efforts needed for the unfinished feature. 

A common strategy when creating a Pega Platform application is to create a branch for each feature your team is developing. A branch for each feature allows your team to independently develop a feature in an isolated space (the branch) without affecting other teams. For example, your team creates one branch to change properties in a form and one to change a UI section. 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.

Check your knowledge with the following interaction:

Each Pega development team creates its own branch and branch rulesets to manage the independent development of features that share rulesets. To avoid impacting the work of other teams, each team also works in a development application that is built from the main application. 

Development applications

To speed up application development, you can support branched development by creating a development application that is built on the production application. Creating a development application is not mandatory but provides an uninterrupted development process, especially for large or multiple development teams that work on the same application. If your developers work in separate groups and would benefit from more isolated development environments, consider building another application on top of the main application for each team. As a result, the names of classes and rulesets remain unchanged. 

In your development application, you can add the main application as a built-on application and provide access to your application for team members. This access helps ensure that different teams and team members can work on different features simultaneously, without the risk of creating errors and conflicts. Each team, working in their own development application, does not see the work from other teams and therefore is neither distracted nor conflicted by it. For example, team members from one team can work on bug fixes that correspond with two separate features but refer to the same base rule, while another team builds more functionality related to one of those features. Each team can conveniently merge changes after the development in a branch is complete.

Consider two development teams building features for a new application. Changes made by each team impact the same application rulesets. To develop rules in parallel using branched rulesets, each team follows these steps:

1. Create a team application that is built on the main application.
   Tip: To create the team application, consider saving a copy of the main application. This ensures the names of classes and rulesets remain unchanged. 
2. Create one or more development branches in the team application.
3. Grant developers access to the team application.
4. Create branches in the team application as needed.
5. Create or update rules by using the branches.
6. Resolve any conflicts between the branches and the application.
7. Merge each branch into the team application rulesets when the development in branches is complete and stable.

After resolving any conflicts between its branch and the team application, the team merges the contents of the branch into the main application rulesets. The following image illustrates the structure of the main application, team applications, and respective team branches. 

Using branches and branch rulesets, a development team creates its team application and development branches to implement a feature in an application without impacting other development teams. After the team resolves any rule conflicts, the system automatically checks which rules are updated and which rules do not exist in the team application before merging the updated rules from the branch into the main application.

The following scenario describes how branches allow one team to update an application without impacting a second team.

Both Team Alpha and Team Beta are updating an Employee Onboarding application. One of the case types in the application allows a new employee to register for direct deposit of their paycheck to their bank account.

Team Alpha is assigned a user story to improve the user experience when users identify a bank account for the direct deposit. The current implementation requires that users enter the bank name and routing number, which leads to processing errors due to incorrect entries. The product owner wants to reduce errors by allowing users to select a bank from a drop-down list that automatically provides the appropriate routing number. At the same time, due to a recent change in the tax code, Team Beta is assigned to update the calculation of tax to withhold for an employee.

While each team works independently, both features involve changes to rules in the same rulesets: HR, HRApps, and HRAppsInt.

In the following image, click the + icons to learn more about how branched rulesets allow Team Alpha to update the UI without impacting the work that Team Beta performed.