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.
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.
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.
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?
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.
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
Posted: 3 years ago
Updated: 3 years ago
Posted: 22 Feb 2018 11:32 EST Updated: 22 Feb 2018 11:31 EST
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?
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?
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.