Best practices for team-based development
Pega Platform™ developers use agile practices to create applications in a shared development environment through the use of branches to commit changes.
Apply the following 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.
- Perform peer review of branches before merging. Create reviews, assign peer reviews from the Branches landing page, and use Pulse to collaborate with your teammates.
- Use Pega Platform developer tools, such as the Rule compare utility, to best address any rule conflict.
- Hide incomplete or risky work by 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). Team B is dependent on the code that Team A developed. The two teams use the same database as the SOR for their code. Team A and Team develop code on different servers uploaded to and downloaded from their shared SOR. A Branch Review is required to move Team B's code from branch ruleset versions to new versions with the main rulesets. They use the lock-new-versions-after-merge approach. Because the new ruleset versions are locked, Team B can pull those new versions into the non-SOR server by using a rebase operation.
- The process begins when Team A requests a branch review against the system of record.
- A Branch Reviewer first requests conflict detection, then runs the appropriate PegaUnit tests. If the Branch Reviewer detects conflicts or any PegaUnit tests fail, the reviewer notifies the developer who requests the branch. The developer stops the process to fix the issues.
- The PegaUnit tests runs.
- If the PegaUnit tests run successfully, the branch merges into the system of record.
- The ruleset versions that are associated with the branch are then locked.
- Remote Team B can now perform an on-demand rebase of the rules of the SOR application 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 is an example:
The following diagram illustrates the Branch Review process for the FSG Email application. The Developer on the left creates a Branch Review for the new FSGEmail code that the development team wants to introduce. The Branch Reviewer performs a code review. Satisfied with the code, the Branch reviewer initiates a merge process. The system checks for conflicts, and branch ruleset PegaUnit tests are run. The branch ruleset code passes the tests and is merged into the main rulesets as new ruleset versions that are immediately locked. When this occurs, the Booking App Team can rebase the rulesets of the FSGEmail application.
Actors:
- Developer: Member of the Enterprise development team responsible for implementing a new feature in the FSGEmail application.
- Branch Reviewer: Member of the Enterprise development team responsible for code review requests from the Developer, and merging if the code review is successful.
- Pega SOR: Pega instance configured as the SOR. This instance 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 any of the PegaUnit tests fail, the reviewer notifies the Developer who requested 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 created to the branch are then locked.
- The Booking App team can now perform an on-demand rebase of the rules of the SOR application into their system.
- A rebase pulls the most recent commits made to the SOR application into the system of the Booking App team.
Always-locked ruleset versions option
Eventually, the team can transition to keeping the non-branched rulesets of the application locked.
When merging a branch, you have two options to facilitate rebase operations:
- Create new version
- Lock target after merge
A system that requests a rebase from the always-locked SOR host of a ruleset detects newly created and locked ruleset versions before proceeding with the rebase or cancel.
Check your knowledge with the following interaction:
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?