Understanding continuous integration and delivery pipelines
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:
- Use third-party tools, such as Jenkins, to start a job and perform operations on your software. For more information, see Configuring a continuous integration and delivery pipeline.
- Use Deployment Manager, where you use Pega Platform as the orchestration server that runs the pipeline, packages your application, and manages importing packages from and exporting packages to repositories that connect from one system to another. For more information, see Understanding model-driven DevOps with Deployment Manager.
- 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