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 –
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.
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****
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..)
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 ?
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.
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.
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..
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.