Understanding rule rebasing
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
Add a Pega repository when you are using the rule rebasing feature to keep applications in sync between environments. Rule rebasing is essential to supporting remote development with Deployment Manager or third-party automation tools.
- 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 automation 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.