Question

Choice of infrastructure for Pega Deployment Manager

Hi Support Community,

Posting this topic to gather recommendations on choice of infrastructure for leveraging Deployment Manager for on premise Pega applications for our customer.

We recommended of having a dedicated Pega instance (where Deployment Manager will be installed) to function as the Orchestrator for the CI/CD pipeline. The customer plans to use the Orchestrator for multiple Pega applications in future.

In order to reduce infrastructure cost and support, customer is asking if we can reuse one of our existing Pega Development instance /infrastructure for this. We can foresee following disadvantages in going with that approach –

  1. By combining the Application Dev and Deployment Manager Pega instances into one , we are increasing dependency as future downtimes in one will impact the other.
  2. A platform version upgrade need for the Application (sharing the infrastructure) mandates upgrade of Deployment Manager Version.

What are the other limitations or challenges others can think of ?

***Edited by Moderator Marissa to update platform capability tags****

Correct Answer
October 14, 2019 - 12:14pm

You will find many of the answers you are looking for in the Deployment Manager FAQ, specifically questions 3 - 6 in the installation series.

 https://community1.pega.com/community/pega-support/question/deployment-manager-faq-installation-and-upgrades

 

 

 

Comments

Keep up to date on this post and subscribe to comments

October 14, 2019 - 4:12am

3. Dedicated server for Deployment Management will also be used as as a repository to keep clean state for current prod deployments. If you combine it with DEV environment (which is more "dirty" because it contains different tools and customized rules for developing), it will be harder to track changes you deploy on next environments (SIT/UAT..)

October 14, 2019 - 10:59am

Thank you for your response @vaspoz . You mean if Pega is chosen as the repository for the jar files for migration then this challenge will arise, right ? Or did you mean this will be the case if customer chooses to have file system / Jfrog  etc as the repository ?

October 15, 2019 - 2:44am
Response to trina_r

No, by repository, I mean Pega type of repository. JFrog/Nexus/etc are also good choices, but you want to have a separate server for Pega instance with Deployment Manager, right?

So, following best practices, you should also properly define your CI/CD pipeline using branches/merges/pushes/automation testing

Say, on DEV environment, a developer makes a branch, and after completion, she should push the branch to the repository (where Deployment Manager - DM - is located). Then DM initializes the pipe, executes some tests, then - if tests passed - merge the branch and proceed with other steps.

 

October 15, 2019 - 9:32pm
Response to vaspoz

If the recommendation here is to use the Pega repository type in the pipeline, I would strongly recommend against it.  While the orchestrator is recommended to be a separate instance, the artifact repository should be its own distinct entity. You can read much more about why this is important in Question 7 in the Installation FAQ.

October 16, 2019 - 3:27am
Response to Linoy Alexander

I fully agree with you. I didn't mean to use Pega as a repo for artifacts. 

There is a misterminology in Pega - when you right click on a branch you ca see "Publish to repository" which actually means - import the branch in another Pega instance which is responsible for orchestration (to run unit tests, merge it, and, in general, to be a main trunk for all developers) and where Deployment Manager should be installed. And during a pipeline execution, all artifacts (packages) should be stored in a separate repository like Nexus etc..

Please correct me if I'm wrong

 

 

October 16, 2019 - 7:17am
Response to vaspoz

You are right, we had piggy backed on the Publish to Repository feature to kick off the CI process for the Deployment Manager pipeline and this was always a little bit of a hacky solution. This is why starting in version 4.4 we implemented the direct publish from the Merge Wizard to the Dev system of record as part of the pipeline, which is where it makes more sense.

October 14, 2019 - 12:14pm

You will find many of the answers you are looking for in the Deployment Manager FAQ, specifically questions 3 - 6 in the installation series.

 https://community1.pega.com/community/pega-support/question/deployment-manager-faq-installation-and-upgrades

 

 

 

October 14, 2019 - 1:52pm

Thanks a lot Lenoy!!! This is extremely helpful thread :)