Table of Contents

Understanding rule rebasing


Only available versions of this content are shown in the dropdown

If you are using continuous integration in a CI/CD pipeline with either Deployment Manager or third-party automation servers such as Jenkins, after you merge branches, you can rebase your development application to obtain the most recently committed rulesets. Rebasing allows development teams working in separate development environments to share their changes and keep their local rule bases synchronized. Having the most recently committed rules on your development system decreases the probability of conflicts with other development teams.

For example, you can publish a branch from your development application to a Pega repository on a source development system, which starts a job on Jenkins as your automation server and merges branches. You can also use the Merge branches wizard to start a Deployment Manager build by first merging branches in a distributed or nondistributed, branch-based environment. After the merge is completed, you can rebase the rulesets on your development application to obtain the merged rulesets.

  • Configuring settings for rebasing

    Before you can rebase your development system, you must first configure a Pega repository and then enable ruleset versions for them. You must also have the appropriate permissions for rebasing.

  • Adding a Pega repository
  • Rebasing rules to obtain latest versions

    If you are using a continuous integration and continuous delivery (CI/CD) pipeline with Deployment Manager or third-party auomation servers such as Jenkins, you can rebase your development application to obtain the most recently committed rulesets through Pega repositories after you merge branches on the source development system.

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.