Skip to main content

Best practices for branch-based development

The Merge pipeline provides the Development team a means to ensure a high quality code and receive feedback faster. As a developer, follow the development best-practices when you work on a branch.

This topic covers the three aspects of working on a branch:

  • Benefits of working on branches
  • Branch-based workflows
  • Best practices of working on a branch and a development application

Development using Rule branch

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.

The following image shows how developers work with branches on a Development environment.
Developers using Rule branches in a Development environment

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.

Understanding branch based workflow

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.

Image depicts a Branch based workflow in which two developers work on the same ruleset version
Multiple developers work on the same rule on the same ruleset version. 
If multiple teams work on the same application, each team should have a separate, remote development server on which developers work. A central Pega Platform server acts as a source development system, which allows teams to integrate features into the application in a controlled manner and avoid unexpected conflicts between teams working in the same rulesets. For more information on development best practices, see development best practices in distributed development process.

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.

Significance of a Development application

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.

Image depicts the steps involved in Application development
Development application built on Production application is used for development activities.

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

Application development best practices

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.

Limitations when using branches 

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.

This Topic is available in the following Module:

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Academy has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice