Best practices for team-based development

Pega Platform™ developers use agile practices to create applications in a shared development environment leveraging branches to commit changes.

Follow these best practices to optimize the development process:

• Leverage multiple built-on applications to develop smaller component applications. Smaller applications are easier to develop, test, and maintain.
• Use branches when multiple teams contribute to a single application. Use the Branches explorer to view quality, guardrail scores, and unit tests for branches.
• Peer review branches before merging. Create reviews and assign peer reviews from the Branches explorer and use Pulse to collaborate with your teammates.
• Use Pega Platform developer tools, such as the Rule compare utility, on how to best address any rule conflict.
• Hide incomplete or risky work using toggles to facilitate the continuous merging of branches.
• Create PegaUnit test cases to validate application data by comparing expected property values to the actual values returned by running the rule.

The following diagram shows how multiple development teams interact with the system of record (SOR).

1. The process begins when Team A requests a branch review against the system of record.
2. A Branch Reviewer first requests conflict detection, then executes the appropriate PegaUnit tests. If the Branch Reviewer detects conflicts or if any of the PegaUnit tests fail, the reviewer notifies the developer who requests the branch. The developer stops the process to fix the issues.
3/4. If the review detects and the PegaUnit tests execute successfully, the branch merges into the system of record.
5.The ruleset versions associated with the branch are then locked.
6. Remote Team B can now perform an on-demand rebase of the SOR application’s rules into their system. A rebase pulls the most recent commits made to the SOR application into Team B's developer system.

For more information, see Development workflow in the DevOps pipeline.

The following Sequence Diagram describes the process using changes to the FSG Email Application as an example:

Actors:

• Developer: Member of the Enterprise development team responsible for implement a new feature in the FSGEmail application.
• Branch Reviewer: Member of the Enterprise development team responsible to code review requests by the Developer, and merge if the code review is successful.
• Pega SOR: Pega instance configure as the SOR. This instances is the master of the last stable changes made to the FSGEmail application.
• Booking App Team: Development team responsible for the Booking and Hotel applications.

Process:

• Enterprise development team implements changes related to a new feature of the FSGEmail application.
• A developer from the enterprise team requests a branch review against the system of record.
• A Branch Reviewer first requests conflict detection, then executes the appropriate PegaUnit tests.
• If the Branch Reviewer detects conflicts or if any of the PegaUnit tests fail, the reviewer notifies the developer who requests the branch review. The branch reviewer stops the process to allow the developer to fix the issues.
• If the review detects no conflicts and the PegaUnit tests execute successfully, the branch merges into the system of record. The ruleset versions associated to the branch are then locked.
• The Booking App team can now perform an on-demand rebase of the SOR application’s rules into their system.
• A rebase pulls the most recent commits made to the SOR application into the Booking App team's system.

When initially developing an application, open ruleset versions are necessary and desirable. At some point, a transition can be made to where the application’s non-branched rulesets always remain locked.

When merging a branch, an option exists to choose Create new version and Lock target after merge. to facilitate rebase operations. A system that requests a rebase from a ruleset's always-locked SOR host detects newly created and locked ruleset versions before proceeding with the rebase or cancel.