Best Practices For Team-Based Development

The document discusses best practices for team-based development on the Pega Platform. It recommends leveraging multiple applications, using branches for contributions from multiple teams, conducting peer reviews before merging, and using Pega developer tools. It also provides a diagram illustrating the workflow between teams using a shared system of record and an example sequence diagram.

Uploaded by

exe6635 9zwoho

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

46 views

Best Practices For Team-Based Development

Uploaded by

exe6635 9zwoho

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 4

10/11/22, 12:32 PM | Pega Academy

Best practices for team-based development

Best practices for System of Record 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.

Multiteam development flow

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

https://academy.pega.com/topic/best-practices-team-based-development/v3/print 1/4
10/11/22, 12:32 PM | Pega Academy

This diagram shows Team B is dependent on code

developed by Team A. The two teams use the same
database as the SOR for their code. Team A and Team
develop code on different servers that are uploaded
to, and downloaded from, their shared SOR. A Branch
Review is required for Team’s code to be moved from
branch ruleset versions to new versions with the main
rulesets. The lock-new-versions-after-merge approach
is used. Because the new ruleset versions are locked,
Team B can pull those new versions into Team B’s non-
SOR server using a rebase operation.

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.

Sequence diagram example

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

https://academy.pega.com/topic/best-practices-team-based-development/v3/print 2/4
10/11/22, 12:32 PM | Pega Academy

This is the Branch Review process illustrated as an

Interaction diagram. The Developer on the left creates
a Branch Review for new FSGEmail code it wants to
introduce. The Branch Reviewer performs a code
review. Satisfied with the code, a merge process is
initiated. A check is made for conflicts and branch
ruleset PegaUnit tests are run. Making it past these
checks, the branch ruleset code is merged into the
main rulesets as new ruleset version that are
immediately locked. When this occurs, the Booking
App Team can rebase the FSGEmail application’s
rulesets.

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:

https://academy.pega.com/topic/best-practices-team-based-development/v3/print 3/4
10/11/22, 12:32 PM | Pega Academy

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.

Always-locked ruleset versions option

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.

https://academy.pega.com/topic/best-practices-team-based-development/v3/print 4/4