Best practices for branch-based development

As a Developer, you work on Rule branches on a shared environment that acts as the System of Record (SOR).

Rule branches are similar to a local developer checkout but different from a traditional code branch. Rule branches do not branch the entire rule base. Using Rule branches, developers can view the latest changes that other developers merge and resolve conflicts before merging the changes.

The following image shows a Development environment on which developers work with Rule branches to view the latest changes other developers merged.

When working on a branch, developers gain the following benefits: 

• Isolated work
• Easy testing
• Targeted collaboration
• Easy rollback
• Merge into the main development environment

The Pega application assesses the changes that a developer makes in a branch by adding the branch to the application stack. 

Developers must validate/test the changes that are enclosed in a branch before merging the rules with the main application ruleset.

Check your knowledge with the following interaction.

Branches allow multiple developers to collaborate on the same ruleset.

The following image shows how Developer A and Developer B are able to work on the same ruleset version.

When using a shared Development environment, teams must adhere to the following guidelines:

• Build a team application layer on top of the main production application. The team Application layer contains branches, tests, and other development rulesets that are not intended for production.
• Create a branch of the production ruleset in the team application.

For more information on development best practices in a shared development environment, see development best practices in shared development environment.

Check your knowledge with the following interaction.

As a developer, use a Development application to maintain a clean Production application. Lock the Production application and modify it only through a merge. Your worklog on the development application layer includes the Development infrastructure rulesets, test ruleset, test data, and other assets. 

The following image depicts the Development and Production applications in which the Development application layer includes different rulesets such as, Dev Infrastructure, Tests, and Test Data.

When you work with a branch to manage the changes made on a Pega application, it has best practices, limitations, and challenges associated with it. 

In this topic, we will learn more about the following aspects of working with a Rule branch: 

• Best practices when using a branch 
• Limitations when using branches and mitigations

Consider following the best practices listed below when you work on a branch:

• Maintain short-lived branches:
  • Leverage release toggles for features in flight.
  • Leverage feature toggles for feature work that spans across multiple Development sprints.
  • Merge a branch only once.
  • Modify the Leverage features outside of a branch in co-ordination with the team.
• Do not add branches to the Production application.
  
• Use the Sandbox environment, which allows the association of Dynamic System Settings (DSS) and classes to branch when planning a major refactor of classes and DSS.

Work with short-lived branches

Merge your branch frequently. Delaying the merge can lead to the following issues:

• Conflict resolution – Resolving conflicts becomes complicated over time with rapidly growing changes. 
• Integration issues – Early testing becomes difficult especially when a production like configuration of the application is unavailable. 
• Tracking dependencies – Managing dependencies between features is difficult as changes are not ready for early integration.

Check your knowledge with the following interactions.

When you work with a branch, managing certain aspects of configuring applications will cause you to encounter the following limitations:

• Modify non-rule-resolved rules
• Modify data instances
• Modify classes in rules 
• Merge withdrawn rules

Explore how you can overcome limitations of working with a branch.

• Non-Rule resolved rules 

  • Create and modify the non-rule resolved rules in a branch. However, you affect everyone on the system even if they do not have the branch, for example: an Application record.
  • Mitigate the impact of non-rule resolved rules by modifying a class directly on the System of Record (Development) environment in coordination with other developers who are affected.

• Data instances 

  • You can introduce data instances through a branch. An extension point enables you to introduce new data type instances through the Merge wizard. However, you cannot modify data instances in a branch.
  • You can manage the impacted data instances in a branch by associating the data instances that must be packaged (by a Release pipeline), with an application ruleset.

• Classes 

  • Though you can introduce new classes through a branch, you cannot modify classes in the branch.
  • To mitigate the challenge of working with existing classes, you can modify the class directly on the System of Record (SOR) (Development) environment in coordination with other developers who are affected.

• Withdrawn rules 

  • You cannot test rules that are withdrawn in branches until after you perform a merge. To address the concerns regarding whether you can test withdrawn rules, use a dedicated branch to withdraw rules and to merge and test the branch independently.