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

Legacy content

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?
   • Ans: Yes, you can build custom repositories starting 7.4. Please refer the following article for more information https://docs-previous.pega.com/devops/84/creating-and-using-custom-repository-types-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.
     • The initial (first time) deployment might be large if the application does not exist on the target system, however subsequent deployments will be quick as only the changes rules and data will be imported as explained above.
     • The Platform import process and subsequently Deployment Manager leveraging the platform import have been tested for multi-gigabyte application packages and it does work but it will take a proportionally long time to deploy.
     • 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.
       • You can get version 3.4.1 from Pega Marketplace
       • Import the PegaDevOpsFoundation from the archive onto the target environments
     • 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
       • Validating test coverage
       • Refresh application quality
       • Scenario testing task
     • 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.

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

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

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

13. 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.
14. I don’t want my test cases to be deployed only to production environment? How do I go about it?
    • Ans: Starting 4.4, Deployment Manager gives you an ability to specify a test application and product rule for the test artifacts. This artifact is deployed independently of your application artifact in the same pipeline, up until the stage chosen by you in the pipeline e.g. you can choose your tests to deploy only on Quality Assurance and not on Staging and Production stages in a pipeline
15. 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.
16. 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.
17. Does Deployment Manager support applying or modifying schema through the pipeline?
    • ​Ans: Deployment Manager relies on the platform import and export capabilities to deploy applications and can handle schema management through the same process. Our recommendation is to let the platform import process, and by extension Deployment Manager, handle schema management ( example introducing new classes/tables, column population for exposed properties). Pega only generates and applies additive schema and does not do any type of destructive schema, so it is safe to stick with this process. For more information on configuring Deployment Manager to manage schema, please follow the instructions on Configuring settings to automatically deploy schema changes.
    • Sometimes company policy dictates that schema needs to go through a DB change management process in which case, you can take away the privilege to automatically apply the schema and then it will automatically pause the pipeline if schema is detected and email the administrator of the pipeline with the schema attached to the email. For more information read the description of the process in Schema changes in application packages.
18. When should a deployment be aborted and when should it be rolled back of a candidate environment?
    1. ​Ans: The decision to abort is really a deployment best practices or business decision, but it is worth clarifying the outcomes between these choices.
       • Abort
         • if you think there is no harm in keeping in the current deployment that failed in the environment (perhaps this is true in QA or other isolated testing environments)
         • if there are other applications being deployed into that environment and you want to avoid rolling back those application changes as well. Currently rollback is environment wide and will affect all users and applications.
         • if there are other users using the environment or is otherwise being used outside of the pipeline tasks (see point above)
       • Rollback
         • if you do want to have the failed deployment potentially impact any future deployments, this should be rare, but there is a potential
         • if the deployment was corrupted in some way and it is safest to rollback
         • if you do not want any user to accidentally use the invalid deployment which could have unknown side effects, particularly critical in Production and perhaps Staging