Deployment Manager FAQ - Installation and upgrades
For a more complete list of questions and troubleshooting tips for Deployment Manager, please reference : Deployment Manager FAQ and Troubleshooting tips.
- Can cloud customers directly download new releases of Deployment Manager from Pega Marketplace?
- Ans: We strongly recommend Pega cloud customers request for new versions of Deployment Manager through Pega Support. The newest versions of Deployment Manager are available simultaneously on both Pega cloud and Pega Marketplace. Having it provisioned through Pega support also ensures that the provided Deployment Manager orchestrator environment is configured correctly and makes support and future management of orchestrator instance easier.
- For cloud customers, will Deployment Manager seamlessly work once Pega support delivers the systems to us after deploying a new Deployment Manager release?
- Ans: After upgrading to a new Deployment Manager version, there might be a few additional steps that need to be executed. Please refer to the upgrade documentation : https://community.pega.com/knowledgebase/installing-upgrading-and-configuring-deployment-manager-44x#upgrading
- Deployment Manager 4.5 supports automatic upgrades from v3.2.1 or later releases of DM : https://community.pega.com/knowledgebase/articles/installing-upgrading-and-configuring-deployment-manager-45x#upgrade
- Where can I get v1.1 or v2.1 of Deployment Manager?
- Deployment Manager v1.1 and v2.1 are no longer supported for Pega Platform 7.3 and 7.3.1 . There are no patches, updates or support for those releases. The oldest version that we support is DM v3.4 for Pega platform 7.4 which can be downloaded from the Marketplace. Our recommendation would be to upgrade the latest version of Deployment Manager v4.5 for Pega Infinity.
- Deployment Manager on Pega Marketplace
- What is the preferred configuration for installation Deployment Manager?
- Ans: The ideal configuration for Deployment Manager to be installed on a separate Pega environment, referred to as an orchestrator. The reasons to install the Deployment Manager application in a separate environment is
- Ensure that the orchestrator environment is stable and it 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 the 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, XLDeployand 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 of the environments connect to the repositories as that is way that the Development environment will publish and share the archives to the higher environments.
- More information about the overall Deployment Manager architecture and workflows can be found here : Deployment Manager architecture and workflows.
- Ans: The ideal configuration for Deployment Manager to be installed on a separate Pega environment, referred to as an orchestrator. The reasons to install the Deployment Manager application in a separate environment is
- Why are there two repositories being used in the pipeline?
- Ans: There really is no need for two different repository instances to be used, you can use the exact same repository for a pipeline. Deployment Manager will automatically create two folders, <repository location>/devops/dev and <repository location>/devops/prod which will be a clear way to know what is the output from the different stages in the pipelins
- Development repository - This will contain the output from the Development environment as part of the Generating artifact task. It will also have a folder named Branches which will contain archives of the all the branches that were merged as part of the pipeline (starting in version 4.4)
- Production repository - This will hold the archives that have made it through the pipeline and where the pipeline user or approver has manually approved through the Approve for production task. In this case the artifact associated with the deployment is fetched directly from the Development repository and copied over to the Production repository location
- The reason to have this separate of development and production repositories (or folders if the same repository location is used) is to ensure that only approved and validated deployment archives are in the production repository. This gives you confidence for the following
- You can trust that the archives in the production repository have passed all necessary validation as part of the pipelines, tests both automated and manual have been run, and it is safe to deploy to the production environment
- Since there is only validation archives in production repository, if you have to roll back or redeploy from on an older version, all of those versions have been similarly validated
- Deployment Manager will only deploy to production from the Production repository giving you confidence that intermediate and potentially buggy and unstable development versions do not make it into production. This is especially true if you lock down access to the production environment and you will only allow Deployment Manager to import new versions of the application.
- Ans: There really is no need for two different repository instances to be used, you can use the exact same repository for a pipeline. Deployment Manager will automatically create two folders, <repository location>/devops/dev and <repository location>/devops/prod which will be a clear way to know what is the output from the different stages in the pipelins
- Why does Deployment Manager require the use of a repository manager to publish and store application artifacts (product rule archives)?
- Ans: There are a few reasons why having a dedicated application artifact repository manager is important.
- Providing stable and reliable access to repositories
- Repository tools such as JFrog Artifactory can be configured to be highly available
- No single point of failure
- Accommodate large load burts
- Supporting a large number of common binaries across different environments
- Scales with the number of binaries
- Manages them across all the different environments without creating multiple copies
- Security and access control
- Implement a security policy that prevents un-validated applications from leaking out to production
- Artifactory provides capabilities such as virtual repositories
- Integration with LDAP, SAML etc
- Complete logging - Tracing any action done to a file back to the user
- Transferring a large number of binaries to a remote location
- Managing infrastructure configuration across different environments
- Providing stable and reliable access to repositories
- You can read more in detail about the benefits of a repository manager directly from JFrog
-
- Ans: There are a few reasons why having a dedicated application artifact repository manager is important.
- Does Deployment Manager support the use of the Pega repository?
- Ans: No, Deployment Manager does not support using the Pega repository type to store application artifacts as part of the pipeline deployment. The Pega repository type currently is only supported the Rebase feature in the platform, and in the future the Rebase feature is also likely to move away from the use of the Pega repository. There are a few reasons why Pega repository should not be used
- The Pega repository stores all the artifacts in the Pega node temporary folder. Each node has it's own temporary folder or working directory to store various caches or other session specific data. This node workspace is not guaranteed to be persistent and can easily be wiped out on restart or when the caches are cleared.
- Pega repository only really works for single node deployments, where there is only one working directory involved. Multi node deployments could end up in a situation where each time a requestor is authenticated it could be in a different node and thus the artifacts published will not be visible.
- Lastly, it is the practice at most companies that lower environments are not allowed to connect directly to higher environments as a general SecOps workflow. Using a Pega repository will force that a Pega environment (likely) a lower one will have access to higher environment breaking this policy.
- If you are looking for a quick and simple way to get started with Deployment Manager without using Artifactory, S3 or other purpose specific artifact management repositories, just use the File system repository, where you can have a network share that is accessible to al the environments involved.
- Ans: No, Deployment Manager does not support using the Pega repository type to store application artifacts as part of the pipeline deployment. The Pega repository type currently is only supported the Rebase feature in the platform, and in the future the Rebase feature is also likely to move away from the use of the Pega repository. There are a few reasons why Pega repository should not be used
- Does Deployment Manager support the use of the defaultstore repository?
- Ans: No, the defaultstore represents the temporary folder associated with the Pega node. It is a system (platform) managed repository and should not be relied to store or persist artifacts. Many of the challenges associated with the use of the Pega repository also apply when using defaultstore.
- What repository should I use on Pega Cloud?
- Ans: If you have been provisioned Deployment Manager on Pega Cloud, you should use the pegacloudcustomerroot repository. This will be automatically configured for you and should not need to be specified in the pipeline. Please see the instructions for referencing repositories in the pipeline as part of the help for additional information.
- What are the recommended size and configuration for the orchestrator instance?
- Ans: A standard Pega install as suggested by the Pega install guide typically used for development environment should be sufficient for the orchestrator environment. Specific requirements will vary on the app server and database being used, but the Pega Platform install guides provide all the necessary information. Being more generous with memory > 8GB is however always a good idea.
- What type of node does Deployment Manager orchestrator need?
- Ans: A standard “default” node type should be sufficient.
- Can on premise customers use an existing environment, such as the development environment, to install Deployment Manager and do double duty as an orchestrator environment?
- Ans: For on prem customer, our recommendation is to always have a separate environment to the Deployment Manager orchestrator. This is how it is deployed for our Pega cloud customers and it provides the following benefits
- Security – Companies often have policies that prevent development environments, or lower environments in general, from being able to connect directly to higher environments especially production. 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 can satisfy this policy.
- Stability – if a dev environment needs to be restarted or is impacted in any significant way, then the DevOps pipelines running in the orchestrator are not affected.
- Scale – A single Deployment Manager orchestrator instance can be used to manage multiple applications each of which will have their own environment stacks. Keeping the orchestrator separate will ensure that all the connectivity necessary between the different environments is handled only at the orchestrator and not between the dev environment
- Ease of troubleshooting – it will be a lot of easier to trouble shoot issues with the pipelines if the devops environment is separate.
- That noted, if you are early in the development cycle and are just looking to get started with a DevOps pipeline, with the goal to migrate to a separate environment in the future, you can proceed with installing Deployment Manager on an existing environment. Follow the installation steps as you would when setting up Deployment Manager for the first time. Please keep in mind the challenges you will face around the points listed above and proceed accordingly.
- Ans: For on prem customer, our recommendation is to always have a separate environment to the Deployment Manager orchestrator. This is how it is deployed for our Pega cloud customers and it provides the following benefits
- My Dev and QA environments are in one VPC, and the production is in a different VPC. How can I leverage Deployment Manager in this case?
- Ans: There are two key requirements in order to make Deployment Manager work across VPCs
- The DevOps orchestrator environment needs to be able to connect through https to all the environments, Dev, QA and Production. This might require whitelisting the DevOps IP addresses, please work with Pega Support in order get this configured
- All the environments, Dev, QA, Prod and the DevOps orchestrator environment need to have a shared artifact store such as S3. Deployment Manager seamlessly stores artifacts generated as you run your deployments in S3 folder assigned to you.
- However, the S3 folders are specific to a VPC and are not accessible across to other VPCs. It will be necessary to procure and configure a repositorythat can be accessed across all the environments. This could include 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 repositoriesthat are not supported out of the box.
- If you would like to continue using the Pega provided S3 solution, then please work with Pega support in order to provision an cross VPC compatible S3 bucket.
- Ans: There are two key requirements in order to make Deployment Manager work across VPCs
- Can the newest version of Deployment Manager, 4.x on orchestrator system manage candidate systems (Dev, Staging and Production) on 7.4?
- Ans: Deployment Manager 4.x series is the version that is compatible with the Pega 8.x platform series. This means that the orchestrator environment needs to be Platform version 8.1 or above in order to use. It is possible to have orchestrator in the Deployment Manager 4.x series manage applications running on Pega platform 7.4 (where the Dev, QA, Stage, and Prod candidate environments where the applications run are on Pega 7.4). This will require that the 7.4 compatible DevOps foundation layer is installed on the 7.4 candidate systems.
- Environments older than Pega 7.4 is not supported.
- However, a lower version of Deployment Manager, ex. version 3.4 on orchestrator system will not be able to support a higher platform versions, ex Platform version 8.1 and above on candidate systems. An article detailing how to set this up correctly will be published in the near future.
- For much more detail on how to set this up, please follow the guide here: Configuring Deployment Manager 4.x for Pega Platform 7.4
- How the the PegaDevOpsFoundation be configured in the candidate environments?
- Ans: Please follow the instructions in the help on configuring candidate environments in the help. Here are a few tips make it easier to maintain this configuration in an ongoing basis
- Use the major version PegaDevOpsFoundation 4 that is also included instead of capping it to the minor version such as PegaDevOpsFoundation 4.6. This will make it so that you don't have to update your application rule every time you upgrade to a new 4.x version of Deployment Manager
- Ensure the the PegaDevOpsFoundation app is in the lowest part of the app stack that gets deployed.
- If there are built on apps (such as a COE application layer) that are shared across multiple apps, the PegaDevOpsFoundation app could be located in there, which makes it easy to share this across all apps that use the built on app. You also avoid the situation where you now have multiple places you need to go an update when upgrading to a newer versions of Deployment Manager.
- Use the major version PegaDevOpsFoundation 4 that is also included instead of capping it to the minor version such as PegaDevOpsFoundation 4.6. This will make it so that you don't have to update your application rule every time you upgrade to a new 4.x version of Deployment Manager
- Ans: Please follow the instructions in the help on configuring candidate environments in the help. Here are a few tips make it easier to maintain this configuration in an ongoing basis