Deployment Manager architecture and workflows
Use Deployment Manager to configure and run continuous integration and delivery (CI/CD) workflows for your Pega applications from within Pega Platform™. You can create a standardized deployment process so that you can deploy predictable, high-quality releases without using third-party tools. With Deployment Manager, you can fully automate your CI/CD workflows, including branch merging, application package generation, artifact management, and package promotion to different stages in the workflow.
Deployment Manager supports artifact management on repository types such as Amazon S3, file system, Microsoft Azure, and JFrog Artifactory. Additionally, in Deployment Manager 3.3.x and later, you can create your own repository types; for more information, see Creating custom repository types for Deployment Manager. Deployment Manager also supports running automations on Jenkins that are not supported in Pega Platform such as running external regression or performance tests. In addition, Pega Cloud pipelines are preconfigured to use Amazon S3 repositories and are configured to use several best practices related to compliance and automated testing.
Deployment Manager is installed on the orchestration server, on which release managers configure and run pipelines. With Deployment Manager, you can see the run-time view of your pipeline as it moves through the CI/CD workflow. Deployment Manager provides key performance indicators (KPIs) and dashboards that provide performance information such as the deployment success rate, deployment frequency, and task failures. Use this information to monitor and optimize the efficiency of your DevOps process.
See the following topics for more information:
- CI/CD pipelines
- Systems in the Deployment Manager CI/CD pipeline
- Repositories in the pipeline
- Pipelines in a branch-based environment
- Pipelines in an environment without branches
A CI/CD pipeline models the two key stages of software delivery: continuous integration and continuous delivery. In the continuous integration stage, developers continuously validate and merge branches into a target application. In the continuous delivery stage, the target application is packaged and moved through progressive stages in the pipeline. After application changes have moved through testing cycles, including Pega unit, regression, performance, and load testing, application packages are deployed to a production system either manually or, if you want to continuously deploy changes, automatically.
The CI/CD pipeline comprises several systems and involves interaction with various Pega Platform servers:
- Orchestration server – Pega Platform system on which the Deployment Manager application runs and on which release managers or application teams model and run their CI/CD pipelines. This system manages the CI/CD workflow involving candidate systems in the pipeline
- Candidate systems – Pega Platform servers that manage your application's life cycle; they include the following systems:
- Development system – The Pega Platform server on which developers build applications and merge branches into them. The product rule that defines the application package that is promoted to other candidate systems in the pipeline is configured on this system. Distributed development environments might have multiple development systems. In this environment, developers develop applications on remote Pega Platform development systems and then merge their changes on a main development system, from which they are packaged and moved in the Deployment Manager workflow.
- QA and staging systems – Pega Platform servers that validate application changes by using various types of testing, such as Pega unit, regression, security, load, and performance testing.
- Production system – Pega Platform server on which end users access the application.
Deployment Manager supports Microsoft Azure, JFrog Artifactory, Amazon S3, and file system repositories for artifact management of application packages.
For each run of a pipeline, Deployment Manager packages and promotes the application changes that are configured in a product rule. The application package artifact is generated on the development environment, published in the repository, and then deployed to the next stage in the pipeline.
A pipeline uses development and production repositories. After a pipeline is started, the application package moves through the pipeline life cycle in the following steps:
- The development system publishes the application package to the development repository.
- The QA system retrieves the artifact from the development repository and performs tasks on the artifact.
- The staging system retrieves the artifact from the development repository and publishes it to the production repository.
- The production system deploys the artifact from the production repository
If you use branches for application development, you can configure merge criteria on the pipeline to receive feedback about branches, such as whether a branch has been reviewed or meets guardrail compliance scores. If there are no merge conflicts, and merge criteria is met, the branch is merged; the continuous delivery pipeline is then started either manually or automatically.
The workflow of tasks in a branch-based pipeline is as follows:
- One or more developers make changes in their respective branches.
- Merge criteria, which are configured in Deployment Manager, are evaluated when branches are merged.
- Continuous delivery starts in one of the following ways:
- Automatically, after a branch successfully passes the merge criteria. If another continuous delivery workflow is in progress, branches are queued and started after the previous workflow has been completed.
- Manually, if you have multiple development teams and want to start pipelines on a certain schedule.
- During a deployment run, branches are queued for merging and merged after the deployment has been completed.
The following figure describes the workflow in a branch-based environment.
In a distributed, branch-based environment, you can have multiple development systems, and developers author and test the application on remote Pega Platform development systems. They then merge their changes on a main development system, from which they are packaged and moved in the Deployment Manager workflow.
The following figure describes the workflow in a distributed, branch-based environment.
If you do not use branches for application development, but you use ruleset-based development instead, you configure the continuous delivery pipeline in Deployment Manager.
The workflow of tasks in this pipeline is as follows:
- Developers update rules and check them in directly to the application rulesets on the development system.
- The product rule that contains the application rules to be packaged and moved through the systems in the pipeline is on the development system.
- Continuous delivery is started manually at a defined schedule by using Deployment Manager.
The following figure describes the workflow of a pipeline in an environment without branches.