Table of Contents

Article

Deployment Manager 1.x.x and 2.x.x

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 (supported in Pega 7.3.1 and later), and JFrog Artifactory. It also supports running automations on Jenkins such as external regression or performance tests that are not supported in Pega Platform .

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.

Deployment Manager version 1.x.x is supported on Pega 7.3, and Deployment Manager version 2.x.x is supported on Pega 7.3.1. You can download Deployment Manager from the Deployment Manager Pega Exchange page.

For more information, see the following PDN articles:

This document describes the features that are available in the most current releases of Deployment Manager 1.x.x and 2.x.x.

CI/CD pipelines

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

Systems in the Deployment Manager CI/CD pipeline

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 workflows on the 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 environment 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.

Repositories in the pipeline

Deployment Manager supports JFrog Artifactory, Amazon S3, and file system (supported in Pega 7.3.1 and later) 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:

  1. The development system publishes the application package to the development repository.
  2. The QA system retrieves the artifact from the development repository and performs tasks on the artifact.
  3. The staging system retrieves the artifact from the development repository and publishes it to the production repository.
  4. The production system deploys the artifact from the production repository.

Pipelines in a branch-based environment

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:

  1. One or more developers make changes in their respective branches.
  2. Merge criteria, which are configured in Deployment Manager, are evaluated when branches are merged.
  3. 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.
  4. During a build run, branches are queued for merging and merged after the build has been completed.

The following figure shows the workflow in a branch-based environment:

Workflow in a branch-based environment

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 shows the workflow in a distributed branch-based environment:

Workflow in a distributed branch-based environmentWorkflow in a distributed branch-based environment

Pipelines in an environment without branches

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:

  1. Developers update rules and check them in directly to the application rulesets on the development system.
  2. The product rule that contains the application rules to be packaged and moved through the systems in the pipeline is on the development system.
  3. Continuous delivery is started manually at a defined schedule by using Deployment Manager.

The following figure shows the workflow in an environment without branches:

Workflow in an environment without branchesWorkflow in an environment without branches

Tags:

Published September 12, 2017 — Updated June 13, 2019


100% found this useful

Have a question? Get answers now.

Visit the Pega Support Community to ask questions, engage in discussions, and help others.