Deployment Manager Configuring the SOR
I am woking with the deployment manager from Pega 7.31 accroding to this Introduction:
https://pdn.pega.com/deployment-manager-version-1/deployment-manager-version-1#systems
The first Step is "Configuring systems and repositories in the CI/CD pipeline", i don't understand what it actually means.
Using the Import wizard, import your existing Pega Platform application to the SOR.
What does is mean with the "existing Pega Platform" and "SOR". Why do we need extra a SOR as a centralized repository. The Pega Platform server has its own rulebase.
From my point of view, the application is running on Pega Platform Server, why do we need to import to the SOR, is it only for a rivision-safe archiving?
***Edited by Moderator Marissa to update categories***
Pegasystems Inc.
US
The overall purpose of the Deployment Manager and associated systems is to allow automated testing and stronger control over the various Pega environments (Dev, Test, Prod, etc.) in a project. The step you mention involves configuring the systems that oversee and control the actual application systems. The System of Record (SOR) doesn't use the rulebase of any of the application systems, but rather does source control (among other things) for the whole project. The SOR controls and tracks branches, for example. Basically, the working environments like Dev and Prod track application rules and data, while the SOR tracks those environments and their branches.
https://docs-previous.pega.com/devops/84/understanding-devops-release-pipeline has an overview that should help - the configuration document explains _how_ to configure these things, this document tells you _why_ you'd want to configure them and what each part of the system does.
Pegasystems Inc.
IN
SOR is the Pega 7 system on which your application resides. It's essentially the source of truth or the build system for your application, where your product rule also resides.
So essentially, if you are not doing distributed development. SOR is just your development environment on which you build rules either on branches or directly on rulesets, and where you also create a product rule that you want to build and deploy.
If you are doing distributed development however, your remote development system may be different from your SOR system in that on the remote development system or systems, developers will build rules, but the source of truth for rules is essentially the SOR (another Pega system), where these branches are eventually merged to the application. It is here that you will create a product rule that you want to deploy to higher environments.
In the upcoming versions of the documentation, we are looking to clarify some of this in a better way, so please stay tuned.
W&W
DE
Thank you very much, i have still some quetions about the Deployment Manager,
- What is a candidate system, i think, it is actually a target system, does it mean, the application would be deployed on a candidate system?
- Pega support only four Repository types, but our company has the SVN system as Application Repository, how could we use it, customization?
Pegasystems Inc.
IN
Candidate systems are all systems that participate in a CICD workflow. They are your Dev, QA, Staging and Production environments that the Deployment Manager orchestrates as you build pipelines for your CICD.
In Release 7.4, we will be releasing a framework that will allow customers to add more repository types for Deployment Manager workflows. Till then we will recommend that you use JFrog and S3 repository types only.
Stay tuned !!
Hope this helps.
W&W
DE
Thanks a lot, it is helpful.
I have tried to add an application pipeline, could you please tell me, what can the pega Step "Deploy" on the stage "Quality Assurance", "Staging" and "Production" accomplish(see screenshot)? What does it mean, do we need to use the Pega Import wizard to import the Application to another enviornments manually?
We have used the prpcserviceutils script to import the application to target enviornment in our releasepipeline.
And what does it mean "The SOR publishes the application package to the development repository." How could the applicaiton be published to the development repository, have seen, in the big picture of release pipeline it is an automated step. But How could it be automated?
Pegasystems Inc.
IN
Deployment Manager automates end to end CICD workflows for you. "Deploy" and "Publish to Prod" repo are implicit steps that Pega performs for you. We show these steps in pipelines for transparency purposes.
The whole workflow works as follows:
1. RAP (artifact) corresponding to the product rule that you specify gets built on the Dev environment (SOR), and gets published in the Dev Repo
2. Now orchestration moves to Quality Assurance stage and artifact (RAP) is automatically deployed from Dev Repo onto the QA stage.
3. Now steps in your QA stage are executed e.g. in your case Pega Unit Testing.
4. Similarly the orchestration moves to Staging, where after deployment of RAP, "Deployment" Jenkins job is executed.
4. Now since Staging is the last stage before Production, same artifact is now published to Prod Repo, indicating that this artifact is production ready and can be deployed on a production environment.
5. Now orchestrator instructs Production stage to deploy the artifact from Prod Repo.
6. Finally "Deployment" Jenkins job is executed on the production stage
Everything is automated end to end. All you need to do is configure this properly and insert your tasks.
Hope this helps.
W&W
DE
i have still one question, what do you mean with this sentence: "RAP (artifact) corresponding to the product rule that you specify gets built on the Dev environment (SOR)"?
Does it mean, the Product file would be exported on the Dev environment, is it actually do the same task as we click the button "create product file"?
Pegasystems Inc.
IN
Yeah, as part of Deployment Manager configuration process, you specify the product rule that you want to get deployed as part of your CICD workflow. The product rule resides on the SOR environment, and Deployment Manager automates the generation of the RAP (like you said, it's same task as we click the button "create product file").
The end to end process for generation, archival and deployment of RAPs and execution of tasks in the pipeline is automated
Updated: 22 Feb 2018 11:31 EST
W&W
DE
i am so glad to hear that "Everything is automated end to end. All you need to do is configure this properly and insert your tasks."
But my release Pipeline had failed at the first step, i think, the problem was the false configuration of my jfrog repository, i have installed a Jfrog Repository on a local machnie, but i don't how to configure it in Pega, the connection status is also failed.
Could you please give me an example, how could a Jfrog Repository be configured.
Which Authentication profile can i use, should i take the same user who is also authenticated by JFrog?
And how about the HostID and Repository key?
I had it so configured, but it worked not:(
HostID: http://localhost:8081/artifactory/webapp/#/artifacts/browse/tree/General
Repository key: /generic-local
Pegasystems Inc.
IN
Can you please configure as follows:
Host id: http://<IP:Port> (this URL should login directly to your JFrog repository)
Repository Key: generic-local (this should be the name of repository created on the JFrog server)
Can you please configure as follows:
Host id: http://<IP:Port> (this URL should login directly to your JFrog repository)
Repository Key: generic-local (this should be the name of repository created on the JFrog server)
Authentication profile: Use basic authentication profile, and specify login credentials for your JFrog server
(Refer to attached file)
W&W
DE
thank you very much for a detailed explanation, i have configured my JFrog Repo. as follows:
Host id: http://localhost:8081/artifactory/webapp/#/home(i have installed it by myself, it is runing on a windows system.)， the landing page of this URL is as the screenshot blow showed.
Repository Key: generic-local (this should be the name of repository created on the JFrog server)
Could you please tell me how i could configutre it in this case.
I have used the default user(admin) and password of Jfrog to configure the Authentication Profil, with this user i can login to JFrog Repo.
But i still get the error msg like this:
Connection Status:
FAILED
Response Message:
Please provide valid Host ID / Credentials / Repository Key. Check log for more details.
Pegasystems Inc.
IN
Hi
Could you please configure as follows and try it
Host id:https://xxx.xxx.xxx.xxx:8081
Repository Key: generic-local
W&W
DE
we have already tried to connect to the JFrog repository with maven type, but the connection could still not be build.
the LDAP authentication was configured on JFrog, is basic authentication allowed according to JFrog security settings? We are trying to connect to JFrog using basic authentication and passing our user credentials.
Our Jfrog colleague has suggested that to use the API key instead of user and password. But i don't know, how could we configure it on Pega?
TCS
GB
Hi Khurs,
I have configured three environments, one for Dev, one for SOR+Orchestration and another for QA. I can publish the branch from Dev to SOR successfully, but Orchestration server is not automatically starting the "Merge Criteria" stage and hence the build is not triggering automatically (I've checked the Box to trigger the build on merge).
Here, the published branches are not appearing in "View Branches" after publishing from the Dev environment. If I start the build manually, then it's throwing http 403 error (Log attached).
I have both Release Manager and the base application, in SOR/Orchestration environment. And authentication profiles, Dynamic System Settings and Access groups are properly configured.
Could you please help me resolve the issue?
Pegasystems Inc.
IN
Yes. It all depends on your own workflow. They can be same or different.
BTW, were you able to fix the other problem with repository configuration ?
W&W
DE
the connection failed even if with a really JFrog repository via a https connection.
HostID: https://artifactory-test.xxxyyyy.com
Repository Key: pega-test
And the user that was configured in Authentication Profile is fully authorized.