Deployment Manager FAQ - General questions
- 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 Managerguide for a minimal set of step by step instructions to start using Deployment Manager.
- 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 typesgenerated 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 usin order to learn more about it.
- 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_CSpipeline 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
- 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
- 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://community.pega.com/knowledgebase/articles/creating-and-using-custom-repository-types-deployment-manager
- 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.
- 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 Devrepository.
- 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.
- 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.
Keep up to date on this post and subscribe to comments