Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Understanding continuous integration and delivery pipelines

Updated on April 5, 2022

DevOps is a culture of collaboration by development, quality, and operations teams to address issues in their respective areas. To sustain progress and bring continued improvement, tools and processes are put in place. Use DevOps practices such as continuous integration and delivery (CI/CD) pipelines to break down code into pieces and automate testing tasks, so that multiple teams can work on the same features and achieve faster deployment to production.

A CI/CD pipeline models the two key stages of software delivery: continuous integration and continuous delivery. In the continuous integration stage, developers can continuously merge branches into a target application. In the continuous delivery stage, the target application is packaged and moved through quality testing before it is deployed to a production environment.

You can set up a CI/CD pipeline for your Pega Platform application using one of two methods:

  • Adding a branch from a repository

    If you are working in a continuous integration and delivery (CI/CD) pipeline, you can add a branch from a repository to your development application. You cannot add a branch that contains branched versions of a ruleset that is not in your application stack.

  • Publishing a branch to a repository

    If you are using a continuous integration and delivery (CI/CD) pipeline with third-party tools such as Jenkins, you can publish a branch from your development application to a Pega repository on the main development system (remote system of record) to start a merge.

  • 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.

  • Previous topic Understanding best practices for version control in the DevOps pipeline
  • Next topic Adding a branch from a repository

Have a question? Get answers now.

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

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us