Candidate and repositories

A candidate system requires the following single rule component to function:

• PegaDevOpsFoundation

By default, the PegaDevOpsFoundation component is shipped with an operator and an authentication profile; both are required for authentication.

• Operator
  • DMAppAdmin
     
• Authentication profile
  • DMReleaseAdmin_OAuth2

If a candidate is on Pega Cloud® services, the PegaDevOpsFoundation is available on the provisioned instance. However, the candidate on-premise or client cloud must download and install this component from Pega Marketplace.

Check your knowledge with the following interaction.

The DMAppAdmin operator ID points to the PegaDevOpsFoundation application. This operator is used to authenticate the request for running tasks on the candidate system. To establish successful communication, enable the DMAppAdmin operator and set a password. The password for the operator must match the password set for the DMAppAdmin authentication profile on the orchestrator system.

You can use a different operator or password for each environment. An authentication profile should exist on the orchestrator system and the operator with the same credentials as that on the candidate system. Each stage in a pipeline can reference a different authentication profile.

A candidate system uses the DMReleaseAdmin_OAuth2 authentication profile to communicate with the orchestration server. This authentication profile is used to obtain information about pipelines, trigger deployments, and post updates to tasks as they are executed.

Because the authentication profile type is oAuth2, update the client secret with the client secret generated on the orchestrator (using the Generate client secret option from General settings on the Deployment Manager studio).

Check your knowledge with the following interactions.

A development system that is either used as the single source of truth or is an instance where the development happens on App Studio or Dev Studio is known as a development candidate system. A development system can play the following roles in a pipeline:

• System of record (SOR) - The SOR is the source of truth for a development team that contains the latest version of an application. The development system's role changes depending on the pipeline template:
   
  1. Deployment pipeline - The development system acts as the first stage to generate an application artifact.
  2. Merge pipeline - The development candidate system acts as the SOR for merging the development changes. The development changes are merged to the SOR after all the quality gates are validated.
      
• Development system - The developer uses this system for development activities. Once the development completes, the developer can merge or publish the changes into a pipeline.
   
  1. An App Studio for a citizen or low-code developer acts as a development system from which an application is packaged and published to a deployment pipeline.
  2. A Dev Studio user can maintain their changes on a branch, and then submit the branch through a merge pipeline that finally integrates the changes to the SOR.

The Deployment Manager stores the application artifacts that are created throughout the life cycle of a deployment in a repository. Use a supported artifact repository to use the Deployment Manager.

Create a repository rule on each candidate system for the candidate to read and write to the repository.

Development repository

The pipeline uses the development repository type to generate artifacts for an application and to version it. The stage in a pipeline that validates an application to certify it as production-ready is responsible for deploying the application artifacts from the development repository.

The Deployment Manager tracks the unique artifacts generated for a deployment.

Production repository

The pipeline uses the production repository type to store the production-ready artifacts. The production repository is optional. You can use a development repository as the Deployment Manager to further separate the production-ready artifacts in a folder that is dedicated to these artifacts.

When a pipeline certifies an application as production-ready, the artifact is then published to a production repository. Any stage that requires deploying a production-ready artifact can indicate the configuration by selecting the Deploy production ready artifacts? parameter on the deploy task configuration.

Pega Platform™ supports a variety of repository vendors. The Deployment Manager packages and promotes the application changes that you configure in a product rule for each pipeline deployment. The Deployment Manager generates the application package on the development environment, publishes the application package to the repository, and deploys the application package to each subsequent stage in the pipeline.

Deployment Manager supports the following repository types:

• Microsoft Azure
• JFrog Artifactory
• Amazon S3
• Nexus 2/3
• File system

Deployment Manager does not support the following repository types:

• Pega
• defaultstore (repository instance included in each Pega deployment)

Pega Platform provides the option to implement a custom repository type if required. For more information, see Creating and using custom repository types for Deployment Manager.

Check your knowledge with the following interaction.