Best practices for team-based development
Pega Platform™ developers use agile practices to create applications in a shared development environment by using version control branches (such as in GIT) to commit changes. This enables multiple developers to work on the same application simultaneously, without interfering with each other's work.
Agile practices involve breaking down the development process into small, manageable tasks that can be completed quickly and efficiently, so that teams can respond quickly to changing requirements and deliver high-quality applications in a timely manner.
The use of branches in a shared development environment enables developers to work on different features or components of the application without affecting the work of other developers. Each developer can create their own branch to work on a specific feature or component, and then merge their changes back into the main branch when they are ready.
This approach allows for greater collaboration and flexibility in the development process, as developers can work independently on different parts of the application while still maintaining a cohesive codebase. It also enables easier tracking of changes and version control, as each branch can be tracked and managed separately.
Overall, the use of agile practices and branches in a shared development environment is an effective way to develop high-quality applications efficiently and collaboratively.
Apply the following best practices to ensure that team-based development using Pega software is efficient, effective, and produces high-quality applications:
- Make use of multiple built-on applications to develop smaller component applications. Smaller applications are easier to develop, test, and maintain.
- Define development standards and guidelines to ensure consistency across the team. This includes naming conventions, coding standards, and documentation standards.
- 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.
- Conduct frequent code reviews to ensure that code is of high quality and meets development standards. This includes reviewing code for security vulnerabilities, performance issues, and maintainability.
- 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.
- Use a CI/CD pipeline to automate the build, test, and deployment process. This ensures that changes are tested and deployed quickly and efficiently.
- Test the application thoroughly to ensure that it meets functional and non-functional requirements. This includes unit testing, integration testing, and performance testing.
Multiteam development flow
The following diagram illustrates how multiple development teams interact with the system of record (SOR). Team B relies on the code developed by Team A. Both teams use the same database as the system of record (SOR) for their code. Team A and Team B develop code on different servers, which is then 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, so Team B uses 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 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?