Parallel development

Workspaces in Pega Platform offer a secure, focused space for developers to build and manage application features independently. Each Workspace is tied to one specific operator with developer access, and is exclusively associated with one application. Within an application, each operator has one Workspace created by default, but an operator can create multiple Workspaces within that application.

Changes remain private within a single Workspace until shared to a Branch, helping avoid rule conflicts when multiple developers work on the same app. Changes become visible to the team only after they are shared to a Branch, merged, and included in an application release.

Workspaces can be enabled with the EnableWorkspace toggle. Developers can choose the right Application Layer for new Rules to ensure proper organization.

Developers can create and switch between multiple Workspaces, which show only their own changes. As a best practice, reuse an existing Workspace when continuing work on the same feature before creating a new one.

Using Branches and Branch Rulesets, a development team creates a 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.

Match the numbers to the following image to learn more about how branched Rulesets allow Team Alpha to update the UI without impacting the work that Team Beta performed:

1. Starting application: The original application does not include changes made by either Team Alpha or Team Beta until each team merges their updates into the application Rulesets.

2. Team Alpha: Team Alpha creates a team application and Branches to provide a drop-down list of financial institutions and automatically populate the appropriate routing number.

3. Team Beta: Team Beta creates a team application and branches to update the calculation for tax withholding.

4. Team Alpha updates: Members of Team Alpha can see the updates to the UI for entering bank information. The team can test the integration to the data source and the auto-population of the routing number to ensure the correct application behavior.

5. Team Beta fixes merge issues: Team Beta sees the original form until Team Alpha merges the updated UI into the main application Rulesets. Errors introduced by Team Alpha can be fixed before merging the Branch, preventing the errors from impacting development efforts by Team Beta.

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

A Branch Ruleset has the following characteristics:

• 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 teams develop two features 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. As illustrated by the image below, developing the completed feature in its own Branch allows the team to continue application development to continue while work on the unfinished feature remains isolated and in progress (shown as Feature Branch A and Feature Branch B).

A common strategy for creating a Pega Platform application is to create a separate Branch for each feature your team develops. With this approach, teams work independently in isolated spaces without affecting the main application or other teams. For example, one team might use one Branch to update properties in a form (Feature Branch A) while another team uses another Branch to modify a View (Feature Branch B). A developer merges changes into the main application only after the feature is complete, conflicts are resolved, and approval is granted.

The following image illustrates this approach using Feature Branch A and Feature Branch B, showing how one feature completes and merges first while the other continues development and is merged later once approved:

Check your knowledge with the following interaction:

Members of an application development team can view information about their branch, such as the Rules that it contains and Guardrail warnings, using Branch quality metrics. 

Monitor the health of a Branch using the following quality metrics:

• Guardrails: Guardrails are settings that determine which elements in an application do not comply with Pega best practices for application development. For example, the Weighted score metric identifies guardrail warnings and their severity.
• Merge conflicts: Investigate potential merge conflicts to identify issues as early as possible. For example, the Total merge conflicts metric shows the number of potential merge conflicts for the Branch.
• Test coverage and Unit tests: Check the number of your Branch Rules that are covered by tests. Review failed tests. For example, the Rules covered metric shows the percentage of Branch Rules that are covered by tests, and the Test pass rate metric indicates the percentage of unit tests that have passed.
• Uncovered Rules: Investigate individual Rules that are not covered by tests of any kind. For example, the Uncovered Rules metric identifies the number of Branch Rules that are not covered by tests.