Discussion

Deployment Manager FAQ - General questions

For a more complete list of questions and troubleshooting tips for Deployment Manager, please reference : Deployment Manager FAQ and Troubleshooting tips.

  1. Should I build application on top of Pega Deployment Manager to start operating Deployment Manager?
    • Ans: No, please log on to Deployment Manager portal directly with DMReleaseAdmin operator. Please see the Getting started with Deployment Manager guide for a minimal set of step by step instructions to start using Deployment Manager.
  1. Can we alter the out of the box case workflow of Deployment Manager?
    • Ans: Deployment Manager offers a simple and standardized workflow to automate deployments to production. We strongly recommend you not to alter the case types generated behind the scenes since it may break existing functionality and it will make it significantly more difficult to upgrade to newer versions in the future. We have on our roadmap an ability to add more stages to your model. If you want to add a custom task, our custom task infrastructure allows you to create tasks specific to your DevOps needs. Please reach out to us in order to learn more about it.
  1. We have more than 4 stages in our DevOps lifecycle, Deployment Manager supports only 4 stages, how should we go about it?
    • Ans: Supporting more than 4 environments in a pipeline is on the roadmap. We have also found that a majority of Pega customers are managing their path to production with 3 to 4 environments. However it is possible to satisfy this workflow with the existing version of Deployment Manager.
      • Create two pipelines for an application to satisfy this requirement.
      • There could be a dev pipeline that is configured to allow the developers merge their changes, which can act as the developer continuous integration pipeline, UPlusCSDevin the example below. In the example below, UPlusCSDev stops at Quality Assurance, and also has the “Produciton ready” checkbox selected. This will ensure that any deployments that successfully pass QA will added to the Prod repository.
      • The Uplus_CS pipeline will be the main pipeline to go to production and here you will avoid the exiting Development or Quality Assurance environments and instead only target the higher environments such as Staging or Production.
      • In the UPlus_CS production pipeline, use the option Deploy existing artifact and pick the completed builds

  1. How do roll back features work on Deployment Manager?
    • Ans: Rollback relies on the Restore Points feature of the Pega platform. The Rollback option is presented to the user only when a step errors out in a deployment. A restore point is automatically generated every time an import happens. Any changes that happen after the import and before the next restore point is generated by any application will be rolled back is the rollback action is triggered. Consider this an alternative to database level restore and rollback for every import at this point in time.
      • NOTE -The rollback execution impacts the entire system and is not scoped to the application. Be careful about using restore when there are multiple independent applications on the system
  1. I have a repository that is not supported by the Pega platform or Deployment Manager. Can we build custom repositories to use with Deployment Manager?
  1. We want pipeline to progress to a stage only after a manual approval, how do we accomplish this?
    • ​​Ans: Deployment Manager supports manual tasks, please add task at an appropriate stage and assign it to the right stakeholder, who should approve it. Deployment will not proceed till the task is approved.
    • NOTE – The operator record for the stakeholder needs to exist on the Deployment Manager environment. If the email address is set correctly on the Operator record, then the approver will get an email notification as shown.

  1. When you deploy the package on QA, Staging and Production, is it a new package that is being generated every time?
    • Ans: Deployment Manager follows the industry best practices DevOps, specifically the principle of Build Once, Deploy Many. In terms of Pega applications, there isn’t an explicit build step, however the application packaging process using the Product ruleis the equivalent of the build step for code based projects. The product archive (package) is generated only on the dev environment, and then published to the Devrepository. Higher environments such as Quality Assurance and Staging will pick the same package from Development repository.
    • If the Production ready option is selected, then once all tasks are successfully completed, the same package is promoted (copied over) to the Prodrepository and from there it’s deployed on Production environment. This will ensure that only fully validated application product archives are available to be deployed to production.
  1. How should the product rule be configured for the application pipelines?
    • Ans: Our recommendation is to always package the entire application for a few reasons
      • Introduce failure tolerance - Creating an entire application package that needs to be deployed to production for each deployment, ensures that if any of your environments get corrupted it is less difficult to reconstruct it. Having the entire application packaged from the last successful run of the pipeline, means not having to figure out what was validated (tested) and approved for deployment.
      • Platform handles delta deployment – the Pega platform already handles delta deployments automatically and the exact rules and data that were imported is documented and captured in the log.
      • Simpler and easier packaging process for developers – by maintaining a consistent product rule, it is significantly easier for application developers as they do not have to keep creating a product rule for every single deployment which can be error prone. This is particularly true if they follow the recommended best practices for a development workflow using Deployment Manager.
  2. Can I use the latest version of Deployment Manager version 4.x to manage application pipelines where the target environments (Development, Quality Assurance, Staging & Production) is on Pega Platform version 7.4 ?
    • Ans: Yes, you can use a newer version of Deployment Manager orchestrator (version 4.x) with targetr environments which are on Pega Platform 7.4.
    • A few things to keep in mind when follow this configuration
      • The target environments should be have PegaDevOpsFoundation v3.4.1 in the app stack.
      • Note the limitations on the tasks that are supported for 7.4. DM 4.x series have introduced a number of new task types that are not compatible with 7.4 platform versions, however all the pipeline tasks that were supported in DM v 3.4.1 will continue to work. The specific tasks that are not supported include
      • Also note that any of the Merge related enhancements such as triggering a pipeline directly from the merge wizard, associating user stories and bugs and so on are not supported until your Dev system is also on Platform version 8.x and the PegaDevOpsFoundation is on 4.5 or greater.
      • In version 4.5, some of the repository related diagnostics will not function properly for 7.4 target environments. This will be addressed in a future release of DM.
      • The Deployment Manager 4.x orchestrator will have to be installed on the latest version of Pega Platform.
      • NOTE - This is a strongly recommended setup as with this approach you are able to take advantage of the latest and greatest features of the Deployment Manager while only being limited in a few tasks overall.
  1. Can I use the latest version of Deployment Manager version 4.x to manage app pipelines where the target environments in Pega Platform version 7.3 or 7.3.1 ?
    • ​Ans: No. The lowest version where Deployment Manager is backwardly compatible is Pega Platform 7.4 . There are a number of significant functional changes introduced in Pega platform 7.4 that makes it difficult to support older versions for Deployment Manager. Our recommendation is to upgrade to Pega Infinity 8.x and take advantage of the latest and complete capabilities of Deployment Manager.
  1. Can I use Deployment Manager for Pega platform version 7.2.2 or earlier?
    1. ​Ans: No. Deployment is only compatible for Pega platform version 7.4 and earlier.
  1. How do I rollback a successful deployment?
    • ​Ans: The rollback feature of Deployment Manager is currently only available for deployment tasks that have failed in some way. When a task fails, the deployment pipeline will pause and let an authorized user, skip the task, rerun the task, abort the task or rollback the current deployment.
    • If you would like the rollback option to be available even in situations where the deployment is technically successful, perhaps there was a business decision to rollback, then the best solution is to the do the following
      • Insert a manual step as the final task in the stage where you wish to have the ability to rollback
      • Ensure that the the manual task is assigned to an user who will make the decision to approve/reject the deployment
      • If the deployment is meant to be rolled back, then reject the deployment either through email or directly in Deployment Manager
      • This will now present you with the options as shown above to either abort or rollback a deployment
      • You can now successfully rollback the deployment
  1. Can I use GitHub / GitLab / Bitbucket / SVN or other Source Code Manager (SCM) tools as a repository with Deployment Manager?
    • Ans: Github, BitBucket, SVN and other SCM tools do not makes sense as a repository for Deployment Manager deploying Pega applications.
      • If you are thinking of using an SCM tool as a version control for rules, that is simply not supported. Pega uses the layer cake concept and ruleset versioning (in the database) and rule resolution as the source control mechanism and that is what you have to rely on.
      • Once you export the application archive (zip file) that contains the deployable application, you should then use a artifact repository such as S3 or JFrog Artifactory or even the Filesystem to store the artifact.
      • This artifact is then used to publish to higher environments. All those repository types are supported by Pega, and other artifact management repository can be supported by following implementing the custom repository type as mentioned above.
      • The Releases feature of Github could be a possible solution, for which a custom repository implementation is needed, but the source control mechanism is not suited for Pega.
  2. I don’t want my test cases to be deployed only to production environment? How do I go about it?
  3. Why are does Deployment Manager only support one active deployment per environment in the pipeline?
    • ​Ans: There are a few reasons for supporting only one deployment per environment at the same time:
      • Pega import process is not thread safe, so if same rule is modified during parallel deployments (application imports), deployments could fail and it will be very challenging to identify which deployment was the source of the failure.
      • Before each deployment, a restore point will be created on that environment. So, in case of parallel deployments, if we are not sure which deployment have caused the failure it again will be challenging to identify which deployment restore point to use .
    • You could of course have multiple, different, pipelines deploying to the same environments, however keep in mind again about the challenging with doing parallel imports on the same environments. If the same set of rules are being imported, there could again be failures that are hard to diagnose and fix.
  4. Can I use Deployment Manager to promote my application from 7.4 Development environments to 8.x QA or Staging environments? We are in the process of upgrading and not all our environments have upgraded yet.
    • Ans: We would strongly recommend against migrating applications in-between environments that are on different platform versions. There are always changes to to the Pega runtime, data model and rule assembly in between releases and while we strive for backward compatibility we cannot make a perfect guarantee. Therefore the application that seems to work fine in the lower 7.4 version, may end up have to go through various upgrade scenarios as part of the deployment to QA or Staging and it will become highly unpredictable.
    • You should upgrade the dev environment first to 8.3, ensure you application is nominally functional, perhaps smoke or unit test and then migrate to higher environments. This is regardless of the use of Deployment Manager. Separately, we have never validated the pipeline working with different versions of PegaDevOpsFoundation and it is highly likely it will not work and we have no intention of making this scenario work for exactly the reason stated above.

Comments

Keep up to date on this post and subscribe to comments

August 21, 2019 - 9:13am

I am looking for how to deploy the deployment manager. 

Should I deploy onto a pega platform application server?  

Is there a need to have a separate  database schema required for the deployment manager? if so what are the recommended size and configuration?  Currently I use pega rules and data schema for the application platform

Does pega deployment manager support load balancing?  If the deployment manager is deployed on pega platfom application, is there any configuration needed to specific the role of the node?

 

 

August 21, 2019 - 11:43am
Response to MendusC9

Here are the responses

Should I deploy onto a pega platform application server?  / Is there a need to have a separate  database schema required for the deployment manager?

Ans : Deployment Manager is a Pega application and hence needs to be deployed on a running Pega instance. Our strong recommendation is to deploy the core Deployment Manager application in its own Pega environment (app server, database / schema stack). You can see more details about it in the response to the question What is the preferred configuration for installation Deployment Manager? in the Installation and Upgrades FAQ.  For more information on why we recommend a separate orchestrator instance please refer to the response to 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? 

What are the recommended size and configuration?

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.

Does pega deployment manager support load balancing? 

Ans : In short yes, Deployment Manager being a standard Pega application supports the same load balancing features as for any other application. You could put Deployment Manager orchestrator server behind a load balancer if needed. All interactions with Deployment Manager orchestrator and the candidate systems (Dev, Stg, Prod etc) are though https requests which will work with the load balancer.  Ensure that the URL for the orchestrator that is used in the configuration is the load balanced host name and not the direct IP addresses (port) associated with the nodes.

If the deployment manager is deployed on pega platfom application, is there any configuration needed to specific the role of the node?

Ans: No specific configuration is needed for the nodes. The default node can be used. 

If you want to understand more about the overall Deployment Manager architecture and workflows, there is a good reference to that here : Deployment Manager architecture and workflows.

Hope this helps.

 

 

 

 

August 21, 2019 - 11:54am
Response to MendusC9

These were all useful questions to clarify, so these questions have been added to the Installation and upgrades FAQ.

August 21, 2019 - 1:38pm
Response to Linoy Alexander

Thanks

October 10, 2019 - 3:23am

Hi Linoy Alexander,

I have one doubt, we Developed code in Pega 7.4 version. But our QA and Stagging Severs are in Pega 8.3 versions I can able to move the code form 7.4 version to 8.3 version by using Pega Deployment Manager?

Thanks,

Satya

October 11, 2019 - 10:06am
Response to satyadeepd

I would strongly recommend against migrating applications in-between environments that are on different platform versions. There are always changes to to the Pega runtime, data model and rule assembly in between releases and while we strive for backward compatibility we cannot make a perfect guarantee. Therefore the application that seems to work fine in the lower 7.4 version, may end up have to go through various upgrade scenarios as part of the deployment to QA or Staging and it will become highly unpredictable.

 You should upgrade the dev environment first to 8.3, ensure you application is nominally functional, perhaps smoke or unit test and then migrate to higher environments. This is regardless of the use of Deployment Manager. Separately, we have never validated the pipeline working with different versions of PegaDevOpsFoundation and it is highly likely it will not work and we have no intention of making this scenario work for exactly the reason stated above.