Deployment Manager versions and installation
Frequently asked questions regarding the versioning and installation of Deployment Manager.
What version of Pega Platform is required for Deployment Manager?
The list of supported versions of Deployment Manager and their corresponding platform versions can be found on the Deployment Manager marketplace page, along with a link to download the latest version. See Installing or upgrading Deployment Manager 5 for the Pega Platform compatibility matrix.
If you want to know more about managing Pega Applications that are not on the same platform version as your Deployment Manager orchestrator system, see Configuring an application pipeline in 5.1.x.
Can cloud customers download new Deployment Manager releases directly from Pega Marketplace?
It is strongly recommended that Pega cloud customers request new versions of Deployment Manager through Pega Support. The newest versions of Deployment Manager are available simultaneously on both Pega cloud and Pega Marketplace.
Provisioning releases through Pega support also ensures that the Deployment Manager orchestrator environment is configured correctly and makes support and future management of orchestrator instance easier. To get started with Deployment Manager on Pega cloud, see Quick-start guide for Deployment Manager on Pega Cloud Services.
Where can I get older versions of Deployment Manager?
Supported versions of Deployment Manager are always available on Deployment Manager marketplace. If a version cannot be found, it is no longer supported.
The oldest supported version of Deployment Manager v3.4 for Pega platform 7.4, which can be downloaded from the Marketplace. We recommend upgrading the latest version of Deployment Manager for Pega Infinity. Deployment Manager supports v4.8.4 for Pega Platform 8.1 and later.
What is the preferred configuration for installation?
The ideal configuration for Deployment Manager is to install a separate Pega environment, known as an orchestrator.
Install the Deployment Manager application in a separate environment to:
- Ensure that the orchestrator environment is stable and is not impacted by development and testing activities that happen as part of standard development and release practices.
- A single orchestrator environment can be used to manage multiple application pipelines across many different Pega environments.
- It can connect to all different target environments safely. There are often policies in place to prevent lower environments from being able to connect to higher environments and this way you can authorize just the orchestrator to connect to all the target environments and lock down access to the orchestrator. This is the model that matches other tools such as Jenkins, XLDeploy, and so on.
- The orchestrator environment can be a standard Pega environment configuration typically used for a development environment.
- This orchestrator environment connects to all the other candidate environments that make up the application pipeline. The orchestrator communicates to the other environments through http or https on port 443.
- The candidate environments also need to connect to the orchestrator environment to send updates and responses using http or https via port 443.
- The orchestrator environment also connects to Jenkins if Jenkins tasks are used as part of the pipeline.
- There are also artifact repositories (Development Repository and Production
Repository) that are used to store the application artifacts (such as product rule
export archives). All environments connect to the repositories as that is how the
development environment publishes and shares the archives to the higher
For more information about the overall Deployment Manager architecture and workflows, see Getting to know the systems and components.
Can my candidate environment exist in different VPCs?
There are two key requirements to make Deployment Manager work across VPCs. The DevOps orchestrator environments must be able to connect through https to all environments (development, QA, production), and all environments must have a shared artifact store such as S3.
The S3 folders are specific to a VPC and are not accessible across to other VPCs. It is necessary to procure and create a repository that can be accessed across all the environments. This includes leveraging any corporate repositories that are already available such as JFrog Artifactory, Azure, S3 or even a network file share, all of which are supported by Deployment Manager.
You also have the option of creating a custom repository for any artifact repositories that are not supported out of the box (see Creating and using custom repository types for Deployment Manager for more information).
If you would like to continue using the Pega provided S3 solution, work with Pega support to provision a cross-VPC compatible S3 bucket.
Can a single system serve as both a development system and an orchestrator?
For on-premises customers, it is recommended to always have a separate environment to the Deployment Manager orchestrator. This is the deployment procedure for Pega cloud customers and provides many benefits to your application.
- Security- Companies often have policies that prevent development environments, or lower environments in general, from being able to connect directly to higher environments. The Deployment Manager orchestrator can be setup to be the only authorized entity that can connect between the different environments with all the appropriate security privileges enforced, which satisfies this policy.
- Stability- If a development environment needs to restart or is impacted in any significant way, then the DevOps pipelines running in the orchestrator are not affected. Rolling back an application on the same system as the orchestrator could cause significant issues.
- Scale- A single Deployment Manager orchestrator instance can manage multiple applications, each of which have their own environment stacks. Keeping the orchestrator separate ensures that all connectivity necessary between the different environments is handled only at the orchestrator and not between the development environment.
How should operators be configured on the orchestrator?
All operators using the Deployment Manager portal should be logging in using the PegaDeploymentManager:Administrators access group.
All users who interact with pipelines via merge requests or App Studio publishing should exist on the system with an appropriate email address if you intend to support email notifications.
Be sure to have each user configure proper notification preference for their needs.
Is the 5.x orchestrator supported with all 4.x candidates?
The 5.x orchestrator is only supported with all the candidates having 5.x PegaDevOpsFoundation and candidates having 4.8.4 PegaDevOpsFoundation.
The generate client secret button is not available after upgrading to Deployment Manager 5.x
After upgrade to 5.x please ensure that your operator has SuperAdmin Access Group. Only users with appropriate privileges can see this option. Also ensure you are connected to a secure link (https).
How do I know if the client secret has updated?
The recent changes can be validated from Dev Studio, open the Deployment Manager client Registration rule and view history.
Which email account should be configured after upgrading to Deployment Manager 5.1 for email notifications?
Deployment Manager 5 uses the default email account for sending email notification and email approval please ensure that test connection is successful for default Account.