Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Setting up candidate environments

Updated on July 14, 2022

Candidate environments are any Pega environment that a Deployment Manager pipeline manages. Most pipelines consist of development, QA, staging, and production environments.

Before you begin: Install the PegaDevOpsFoundation application on each candidate environment.
Perform the following steps to set up a candidate environment.
Note: If you did not enable SSL on the candidate environment, you must deselect Require TLS/SSL for REST services in this package for the cicd, api, and DevelopmentStandards service packages. Pega does not recommend this configuration.
  1. On each candidate system, enable the DMAppAdmin operator ID.
    If you want to create your own operator IDs, ensure that they point to the PegaDevOpsFoundation application.
    1. Log in to each candidate system as an administrator.
    2. From the Dev Studio header, click RecordsOrganizationOperator ID, and then click DMAppAdmin.
    3. On the Edit Operator ID rule form, click the Security tab.
    4. Clear the Disable Operator check box.
    5. Click Save.
    6. Click Update password.
    7. In the Change Operator ID Password dialog box, enter a password, reenter it to confirm it, and then click Submit.
    8. Log out of each candidate system.
  2. For development environments, update the OrchestratorURL Dynamic System Setting in the PegaDevopsShared ruleset to point to the orchestrator. Use this setting for Dev Studio and App Studio integration. The URL should end in /prweb (though this is customizable).
  3. Create and configure a keystore named DMKeyStore.
  4. If your target environment is SSL-enabled with private certificates, configure the Deployment Manager connectors so that they can receive and process information by setting the keystore:
    1. Click Switch to Dev Studio Record explorer to create and configure a keystore. For more information, see Creating a keystore for application data encryption
    2. Configure the PegaDeploymentManagerIntegrationsTrustStore dynamic system setting to reference the keystore ID by clicking RecordsSysAdminDynamic System Settings.

    For more information about dynamic system settings, see Creating a dynamic system setting.

  5. If the candidate system is between Pega Platform 8.1 and Pega Platform 8.5.1, the candidate must have 4.8.4 Pega DevOps Foundation. If candidates are managed by an orchestrator on version 5 or later, you must create the PegaDevopsShared configuration and set the value to True. If not set, the candidate will fall back to using the older 4.x APIs for interactions with Deployment Manager and the pipelines will not be functional if using a 5.x orchestrator. Having the configuration created and set to true will ensure the candidates would leverage the 5.x API service.
    • Owning ruleset: PegaDevopsShared
    • Purpose: deploymentmanager/orchestrator/managed_by_5x/enabled
    • Value: True

Setting client secret on the candidate environment

Deployment Manager cannot automatically populate the client secret to candidate environments as we do not recommend that you share this information across systems.

To manually update the client secret information (from Step 2 above) on your candidate environment:
  1. In Dev Studio, from the Records Explorer, navigate to Security Authentication Profile to receive a list of profile names on the candidate environment.
  2. Select the DMReleaseAdmin_OAuth2 authentication profile.
  3. Update client secret on the authentication profile, and follow the steps below as applicable:
    1. If your candidate system is on Pega Platform 8.3 or above, on the OAuth 2.0 tab under the Client configuration section, enter the client secret in the Client secret field.
    2. If your candidate system is on Pega Platform 8.2 or below, update the client secret in the DMReleaseAdmin_OAuth2 authentication profile. Update Access token endpoint and Revoke token endpoint in DMCustom O Auth 2.0 Provider.
  4. Under the Endpoint configuration section, enter the Access token endpoint and Revoke token endpoint.
  5. Click Save.

Configuring the development system for branch-based development

If you are using branches in\a distributed or non-distributed branch-based environment, configure the development system so that you can start deployments when branches are merged. Configuring the development system includes defining the URL of the orchestration server, creating development and target applications, and locking application rulesets.

  1. On the development system (in nondistributed environment) or the main development system (in a distributed environment), create a dynamic system setting to define the URL of the orchestration server, even if the orchestration server and the development system are the same system.
    1. Search for the OrchestratorURL dynamic system setting.
    2. Click on OrchestratorURL to open the rule.
    3. On the Settings tab, in the Value field, enter the URL of the orchestration server in the following format: http://hostname:port/prweb/.
    4. Click Save.

      For more information about dynamic system settings, see Creating a dynamic system setting

  2. Complete the following steps on either the development system (in a non-distributed environment) or the remote development system (in a distributed environment).
    1. Use the New Application wizard to create a new development application that developers will log in to.
      This application allows development teams to maintain a list of development branches without modifying the definition of the target application.
    2. Add the target application of the pipeline as a built-on application layer of the development application by first logging into the application.
    3. In the header of Dev Studio, click the name of your application, and then click Definition.
    4. In the Built-on application section, click Add application.
    5. In the Name field, press the Down arrow key and select the name of the target application.
    6. In the Version field, press the Down arrow key and select the target application version.
    7. Click Save.
  3. Lock the application rulesets to prevent developers from making changes to rules after branches have been merged.
    1. In the header of Dev Studio, click the name of your application, and then click Definition.
    2. In the Application rulesets section, click the Open icon for each ruleset that you want to lock.
    3. Click Lock and Save.
  4. Copy the development repository that you configured on the remote development system to the source development system.
  5. If you are managing test cases separately from the target application, create a test application. For more information, see Managing test cases separately in Deployment Manager.
  6. Optional: To rebase your development application to obtain the most recently committed rulesets after you merge your branches, configure Pega Platform so that you can use rule rebasing.
    For more information, see Understanding rule rebasing.
What to do next:

Previous: Setting up the orchestrator

Next: Securely authenticating in Deployment Manager

Tags

Pega Platform 8.7 DevOps

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Visit the Support Center

Did you find this content helpful?

Yes
No

Want to help us improve this content?
Suggest an edit

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us