Discussion
Pegasystems Inc.
US
Last activity: 22 Apr 2022 15:53 EDT
Ask the Expert - Deployment Manager with Meenakshi Nayak and Pallavi Gurram
Join Meenakshi Nayak @nayam and Pallavi Gurram @gurrp1 in this Ask the Expert session (April 11 - April 22) as they answer your questions on Deployment Manager!
Be sure to Favorite and Follow for updates! This session will open to questions from you on the 11th of April!
Meet your Experts:
Hi, my name is Meenakshi and I am the Product Owner for Deployment Manager and the DevOps practices in general with Pega Application. I have been with Pega for a 1.5 years and my journey here has been fantastic! I started my career as a full stack developer and have 7yrs of development experience. I was introduced to DevOps in 2014 with a mindset that it should be a short project however I got fascinated with PowerShell scripting so much that I continued with creating a custom framework to deploy heterogenous technologies and have now been involved with DevOps for 8 years!
We are constantly evolving and I play a key role in creating that vision for the product, Without hearing from the users, a critical part of my role is incomplete.
Hi, my name is Pallavi and I am an Architect for Deployment Manager! i started my career as a Java developer and have 7 years of development and design work in Java. The rest of my experience is with Pega development and designs! The past 2 years I have been dedicatedly working on Deployment Manager architecture and design.
Message from your Experts:
We are pleased to address all of your questions on the Pega Deployment Manager. Over the course of the session, we will be answering your questions on Deployment Manager, Deployment best practices and how Deployment Manager adds value over any other tools when Pega applications deployed automatically. We look forward to hear from you all. We welcome any feedback from your experience with Deployment Manager as we strive to make Deployment Manager easy to use and add value to serve the unique needs of our users.
Before we get started, here are some essential links that can help you learn more about the product –
Integrate with external tools with Build your own task
Deployment Manager Mission on Pega Academy
Pegasystems Inc.
GB
This session is now open for your questions!
Ask the Expert Rules
- Follow the Pega Collaboration Center's Guidelines
- This is not a Live Chat - Meenakshi and Pallavi will reply to your questions over the course of the 2-week session
- Questions should be clearly and succinctly expressed
- Questions should be of interest to many others in the audience
- Have fun!
Cox
IN
@MarissaRogers @GURRP1 @nayam I need to integrate Pega DM with the Jira Tool in order to update the JIRA user story whenever a deployment is completed. So in this issue, I couldn't see any other task just like integrating with Jenkins and if there are any specific steps or procedure or step by step configuration guide to Integrate successfully with JIRA. Kindly suggest.
Updated: 11 Apr 2022 6:00 EDT
Pegasystems Inc.
IN
@RajaKullaiahD3386 Out of the box deployment manager don't support integration with Jira. But using custom task you can achieve this requirement. Please refer to link https://docs-previous.pega.com/devops/85/creating-and-using-custom-tasks for more information and guidelines on creating custom tasks.
Cox
IN
@Pallavi Gurram Are there any successful implementations of this jira integration earlier? Do we have step by step procedure or configurations for the JIRA Integration custom task? How we need to approach for the solution using REST API's and what are the essential things we need from JIRA Tool in order to integrate successfully? Kindly suggest.
Pegasystems Inc.
IN
@RajaKullaiahD3386 We don't have case study of customer who implemented Jira integration. Deployment API request can be populated with agileWorkbenchItems information, so that deployment manager can keeps track of changes. So that, using JIRA APIs push agileWorkbenchItems information to JIRA using custom task.
Please note that agileWorkbenchItems was introduce to integrate with agile studio OOTB.
Cox
IN
@Pallavi Gurram So connecting with OOTB AgileWorkBench is a necessary thing in order to make a connection to JIRA and push data to JIRA. Kindly elaborate on it.
Thank you
Pegasystems Inc.
IN
@RajaKullaiahD3386 Not required, the intension here is, even for Jira work items can be tracked using agileWorkbenchItems property. so that in reports of deployment work bench items can be displayed.
Updated: 14 Apr 2022 6:42 EDT
Cox
IN
@Pallavi Gurram In the sense, we need to create identical or analogous JIRA items in agile workbench and track the Jira user stories from the AgileWorkBench property. So after that we need to build a custom task to push the information from Agile Workbench to JIRA using the JIRA API's. Is it correct?
Thank you
Pegasystems Inc.
IN
@RajaKullaiahD3386"we need to create identical or analogous JIRA items in agile workbench" is not required. When triggering deployment ensure that you are pushing JIRA items in agileWorkbenchItems property as part of request to POST Deploy API. So that JIRA Items can be displayed in Orchestrator under pipeline reports in changeset section automatically.
Use same property in custom task to push status of JIRA items to JIRA.
Updated: 15 Apr 2022 10:36 EDT
Cox
IN
@Pallavi Gurram Thanks for responding.
1.What are the configurations required to invoke POST Deploy API? If there are any configurations we can do to post the data to Agile workbench items it'll be helpful.
2. Where can i get those details about the Deploy API? Usually, API's require all the connecting parameters to post or get data from them
3. Are there any background agent activities involved or technical ? As I could see very little usage of AgileWorkbench Pagelist property in the PegaDM.
4. Since we are mentioning about the AgileWorkbench property, can this jira update task is mostly linked to the merge pipeline. Please confirm
Cox
IN
@MarissaRogers @GURRP1 @nayam Regarding the Rollback Feature and limitations in Pega DM.
I'm rolling back a failed deployment using the rollback option in the task available as shown in screenshot. But it's rolling back upto the application level which means it can rollback only the rule instances and then how about the Database transactions such as DB Instances or Data objects that were part of the Product rule?
How can I rollback those DB Instances in case pega isn't supporting the full Rollback of the Db instances of internal or external tables involved? Kindly suggest.
Pegasystems Inc.
IN
@RajaKullaiahD3386 It seems the application being deployed in on Platform version 8.1 to 8.3. Application level rollback is supported from 8.4 only and it handles both the Data instances and Rules. Please see https://docs.pega.com/system-administration/84/rolling-back-restore-point
Deployment Manager currently supports the default rollback strategy offered by Pega platform.
I hope this helps.
Cox
IN
1. So without the usage of the prpcserviceutils tool I can't restore both data and rules in case of a failure?
2. In order to install prpcserviceutils tool it needs access to the Jenkins validation engine which i'm not aware of. Could you please help me to prpcserviceutils tool on my machine, so that i can work on running the commands available for restoring.
Thank you
Pegasystems Inc.
IN
@RajaKullaiahD3386 Deployment Manager supports the rollback at application level provided you are on Platform version 8.4 or above. Please see - https://docs-previous.pega.com/devops/86/rolling-back-deployment
Deployment Manager does DB rollback if your app is on 8.3 and application rollback if your app in on =>8.4.
Cox
IN
Appreciate your patience @nayam .
Since i'm using Pega Platform 8.6.1 it'll be undergoing application rollback. Application rollback means what are the things it'll include ( for Eg. Rule instances in RSV & Data instances)? In case Data instances also rollback then it include the Data instances only from Pega internal tables or external tables as well? Pls elaborate.
Thank you.
Pegasystems Inc.
IN
@RajaKullaiahD3386 In application level rollback by default application rules are considered for rollback. Incase of data instances rollback is performed only on classes with "Bypass History on Save" with value "False" in Advanced tab of data class. Case work object by default excluded from rollback.
Pegasystems Inc.
US
@MarissaRogers@nayam @GURRP1 Client is using Deployment Manager on Platform 8.6.1. They have recurring situations where QA team asks to back out some rules (ex. they need more time to fix the defects) from a deployment package right before the production release. In our current process, we unlock the targeted ruleset version (which was previously deployed to QA), make them all "Not Available", and redeploy it to QA. I believe this manual task creates added maintenance/overhead to CI/CD and also unlocking rulesets is not a Pega best practice.
Using Pega Deployment Manager, what would be our recommended solution to address the need for QA team?
Pegasystems Inc.
IN
@Will ChoYou are right in saying that the manual practice of withdrawing rules is not recommended and it can cause issues if impact analysis is not robust. I see the team has a bigger issue to address with the development practices they follow. We should focus on continuous testing with automation in place for Unit tests such that the quality of change delivered to QA itself will improve. Shift-left on identifying issues early and addressing the issues should be the focus. Using merge pipeline in Deployment Manager with tests in place will help gate the quality.
Pega does not recommend snowflake deployments where what was generated at Development stage is further altered in QA or Pre-Prod. All the changes should be made at Development stage and then promoted across in a consistent manner.
Hope this helps.
Active2
DE
Pega does not recommend snowflake deployments where what was generated at Development stage is further altered in QA or Pre-Prod. All the changes should be made at Development stage and then promoted across in a consistent manner.
Thank you for this important information.
Pegasystems Inc.
US
@nayam Thank you for your input and this makes sense to me. We'll emphasize "Shift-left on identifying issues early and addressing the issues should be the focus." to continually improve our CI/CD and minimze the backout scenario.
Client will still ask one thing though. Even if they adopt the best practice as recommendated, an exception can happen where they want to back out some features from a deployment package because they found last minute blockers. Say they asked to remove two ruleset - one with 25 rules, and the other with 12 rules. Client still needs to deploy the package (for other features tested) to production the next day. What would be Pega's recommendation in this exception scenario?
Pegasystems Inc.
IN
@Will ChoI assume you are talking about a specific Ruleset version. If you want to remove a ruleset version from the application version you are releasing, then the only option you have is post deployment. You will have to modify the application version record. This is not recommended, as such last minute changes are not functionally validated and regressed. Such change should still be moved over the CD process.
Updated: 15 Apr 2022 7:37 EDT
Pegasystems Inc.
US
@MarissaRogers @GURRP1 @nayam Client is asking if there is any "default pipepline model" that is already configured with best practices and that client can start with in building a new pipeline. For example, what are the recommended steps in Development stage? and etc. Appreciate if you can point us to a right direction.
Pegasystems Inc.
IN
@Will Cho This is available in 5.x version where you have pipeline templates that guide you through the best practice for the use case like Deployment (CD), Merge (CI), Revision Management (CDH Specific workflow). Please see https://docs.pega.com/devops/86/best-practices-using-pipelines-deployment-manager
ASB
NZ
@MarissaRogers @GURRP1 We have setup up pega deployment manager 5.4 on pega platform 8.6.1. We have 15 applications and created pipelines respectively. Our intention is to have same tasks for each pipeline to maintain consistency. Only we have access to manage or update pipelines. The biggest overload is to update 15 pipelines every time if we need to add or delete a task. Can we have a single pipeline that can be used by all applications since pipeline model is same for all 15 applications?
Thanks
Pegasystems Inc.
IN
@VinodB053Can you elaborate on the specific change you mentioned? What are the use cases where you will change the pipeline?
Right now we do not have the ability to bulk update the pipelines. We had envisioned customer specific templates which is in our long run roadmap, but even that will not solve the problem you are stating. I can take this up as a feedback.
You can use Save as feature to replicate the change to new pipelines but existing pipelines can't be edited. We recommend changing one pipeline and testing out the change before performing the change across other pipelines.
ASB
NZ
@nayam and @GURRP1 Pega recommends always to include entire application in product rule while deploying with deployment manager. In that case DM generates artifacts which are high in size for each deployment for small changes like 1 or 2 rules changes which inturn delays deployment since it takes long time to generate artifact. How can I handle this to make it quick? We don't have control on non versioned rules and data instances because developers may update data instances in development environment like endpoint URLs. How can I handle this?
Thank you
Pegasystems Inc.
US
A huge thank you to @nayam and @GURRP1 on this Ask the Expert session on Deployment Manager!
We had some great conversations throughout the past 2 weeks!
Thank you to everyone who participated in this session!
Keep an eye out on our next session next month with @KenshoTsuchihashi on Pega Platform!
Hope to see you all around the boards!