Skip to main content


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

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

Using Deployment Manager 3.1.x

Updated on September 10, 2021

Use Deployment Manager to create continuous integration and delivery (CI/CD) pipelines, which automate tasks and allow you to quickly deploy high-quality software to production.

On the orchestration server, release managers use the DevOps landing page to configure CI/CD pipelines for their Pega® Platform applications. The landing page displays all the running and queued application builds, branches that are to be merged, and reports that provide information about your DevOps environment such as key performance indicators (KPIs).

This document describes the features for the latest version of Deployment Manager 3.1.x.

See the following topics for more information about using Deployment Manager to configure and use CI/CD pipelines:

Adding an application pipeline

When you add a pipeline, you specify both pre-merge and post-merge criteria. For example, you can specify that a branch must be peer-reviewed before it can be merged, and you can specify that Pega unit tests are run after a branch is merged and is in the QA stage of the pipeline.

You can create multiple pipelines for one version of an application. For example, you can use multiple pipelines in the following scenarios:

  • You want to deploy a build to production separately from the rest of the pipeline. You can then create a pipeline that has only a production stage or development and production stages.
  • You want to use parallel development and hotfix life cycles for your application.

To add a pipeline, perform the following steps:

  1. Click Deployment Manager in the Designer Studio footer.
  2. Click Add application pipeline.
  3. Optional: Specify tasks that must be completed before a branch can be merged in the pipeline.
    1. Click Add task.
    2. From the Type list, select Pega, and then specify the task that you want to perform.
      • To specify that a branch must meet a compliance percentage before it can be merged:
        1. From the Task list, select Check for guardrails.
        2. In the Weighted Compliance Score field, enter the minimum required compliance percentage.
        3. Click Submit.
      • To specify that a branch must be reviewed before it can be merged:
        1. From the Task list, select Branch review.
        2. Click Submit.
    3. Optional: To start a build when a branch is merged, click the Trigger build on merge check box.

One of the following results occurs:

  • If no build is running in the pipeline, and a branch is successfully merged, the build is started by the operator who is logged in to the orchestration server.
  • If a build is running, and a branch is successfully merged, the build is queued for processing. The build will be started by using the operator ID that you defined in this dynamic system setting.
  1. Optional: Clear a check box for a build life cycle stage to skip it.
  2. Optional: Clear the Production ready check box if you do not want to generate an application package, which is sent to the production repository. You cannot clear this check box if you are using a production stage in the life cycle.
  3. Optional: In the build life cycle stages, specify the tasks to be performed during each stage of the pipeline.
    1. Click Add task.
    2. From the Type list, select Pega, and then specify the task that you want to perform.
      • To run all Pega unit tests in the application, from the Task list, select Pega unit testing. For more information about creating Pega unit tests, seeCreating PegaUnit test cases.
      • To run a Jenkins job that you have configured, do the following actions:
        1. From the Task list, select Jenkins.
        2. In the Job name field, enter the name of the Jenkins job (which is the name of the Jenkins build) that you want to run.
        3. In the Token field, enter the Jenkins authentication token.
        4. In the Parameters field, enter parameters, if any, to send to the Jenkins job.
  • To add a manual step that a user must perform in the pipeline, do the following tasks:
    1. From the Task list, select Manual.
    2. In the Job name field, enter text that describes the action that you want the user to take.
    3. In the Assigned to field, press the Down Arrow key and select the operator ID to assign the task to.
  1. Click Review pipeline. The system generates tasks, which you cannot delete, that the pipeline always performs, for example, for deploying the application to each stage in the pipeline.
  2. Click Next.
  3. Optional: If you added a Jenkins step, specify Jenkins server information in the Add application dialog box, in the Jenkins server section.
    1. In the URL field, enter the URL of the Jenkins server.
    2. In the Authentication profile field, press the Down Arrow key and select the authentication profile on the orchestration server that specifies the Jenkins credentials to use for Jenkins jobs.
  4. In the Environments section, specify the URL for the development and candidate systems that are in your pipeline, and also specify merge targets.
    1. Specify development system information:
      1. In the Development field, enter the URL of the development system.
      2. In the Authentication profile field, press the Down Arrow key and select the authentication profile that you want to communicate from the orchestration server to the development system.
    2. Specify the URL of the candidate systems and the authentication profiles that the orchestration server uses to communicate with candidate systems. You should select the authentication profile that you configured in step 4 in Configuring candidate systems in Installing and configuring Deployment Manager 03.01.01. Fields are displayed only for the pipeline stages that you selected in the build lifecycle on the previous page.
  5. Specify options for merging branches into the base application.
    1. Do one of the following actions:
      • To merge branches into the highest existing ruleset in the application, click the Highest existing ruleset radio button.
      • To merge branches into a new ruleset, click the New ruleset radio button.
    2. Optional: In the Password field, enter the password that locks the rulesets.
  6. Select the development and production repositories to which you want to submit application packages. Complete one of the following tasks:
  • If you are using Deployment Manager on-premises, complete the following tasks:
  1. In the Application repository section, in the Dev repository field, press the Down Arrow key and select the repository that connects to a candidate system from the development system. The archived product rule that contains the application in your pipeline is sent from the development system to the candidate system to which this repository connects.
  2. In the Production repository field, press the Down Arrow key and select the production repository. The archived product rule that contains the application is sent from a candidate system to the production system to which this repository connects.
  • If you are using Deployment Manager on Pega Cloud and want to use different repositories other than the default, complete the following tasks:
  1. In the Artifact repository section, click the Yes radio button.
  2. In the Dev repository field, press the Down Arrow key and select the development repository.
  3. In the Production repository field, press the Down Arrow key and select the production repository.
  4. Click Save.
  5. Click Next.
  1. Specify the application and the application contents that you want to build in your pipeline by completing the following steps:
    1. In the Pipeline field, enter a name for the pipeline.
    2. In the Application field, press the Down Arrow key and select your application.
    3. In the Version field, press the Down Arrow key and select the application version.
    4. In the Product rule field, press the Down Arrow key and select the product rule that defines the contents of the application.
    5. In the Version field, press the Down Arrow key and select the product rule version.
    6. Optional: Add dependent applications. For more information, see Product rules: Listing product dependencies for Pega-supplied applications.
    7. ClickAdd.

Modifying stages and tasks in your pipeline

You can add and remove tasks from the stages in your pipeline, if there are no builds are running. You can also add and skip pipeline stages. However, if you add a stage that you did not originally configure, you cannot configure details for it.

  1. Click Deployment Manager in the Designer Studio footer.
  2. Click the pipeline that you want to modify.
  3. Click Actions > Edit pipeline.
  4. Optional: Add and remove tasks to the stages in your pipeline.
  5. Optional: Add or skip stages in your pipeline.
  6. Click Review pipeline.

For detailed information about modifying your pipeline, see Adding an application pipeline.

You can modify application and environment details, such as the product rule to use and the URLs of the systems in your pipeline. See Modifying application and environment details for more information.

Modifying application and environment details

You can modify application details when there are no builds running on a pipeline.

  1. Click Deployment Manager in the Designer Studio footer.
  2. Click the pipeline that you want to modify.
  3. Click Actions > Settings.
  4. To modify the product rule and version that defines the content of your application, do the following tasks:
    1. Click the Edit icon edit iconin the Application Details section.
    2. Optional: Specify the product rule version, and add or remove dependent applications.
    3. Click Save.
  5. To modify environment details, do the following tasks:
    1. Click the Edit icon edit icon in the Environment Details section.
    2. Optional: Specify information such as the URLs to your pipeline systems and the authentication profiles to apply to each system.
    3. Click Save.

For detailed information about modifying your pipeline, see Adding an application pipeline.

Manually starting a build

Start a build manually if you are not using branches and are working directly in rulesets.

You can also start a build manually if you do not want builds to start automatically when branches are merged. You must also clear the Trigger build on merge check box in the pipeline configuration.

  1. Click Deployment Manager in the Designer Studio footer.
  2. Click the pipeline for which you want to start a build.
  3. Click Start build.
  4. Start a new build or deploy an existing application by completing one of the following actions:
  • To start a build and deploy a new application package, do the following steps:
    1. Click the Generate new artifact radio button.
    2. In the Build name field, enter the name of the build.
    3. Click Deploy.
  • To deploy an application package that is on a cloud repository, do the following steps:
  1. Click the Deploy an existing artifact radio button.
  2. In the Build name field, enter the name of the build.
  3. In the Select a repository field, press the Down Arrow key and select the repository.
  4. In the Select an artifact field, press the Down Arrow key and select the application package.
  5. Click Deploy.

Starting a build in a branch-based environment

In non-distributed, branch-based environments, you can immediately start a build by submitting a branch into a pipeline in the Merge Branches wizard. For more information, see Submitting a branch into a pipeline.

Starting a build in a distributed branch-based environment

If you are using Deployment Manager in a distributed, branch-based environment and using multiple pipelines per application, first export the branch to the remote development system, and then merge it.

  1. On the development system, package the branch. For more information, see Packaging a branch.
  2. On the remote development system, import the branch by using the Import wizard. For more information, see Importing a file by using the Import wizard.
  3. On the remote remote development system, start a build by using the Merge Branches wizard. For more information, see Submitting a branch into a pipeline.

If you are using one pipeline per application, you can publish a branch to start the merge. For more information, see Publishing a branch to a repository.

Completing or rejecting a manual step in a build

If a manual step is configured on a build, the build pauses when it reaches the step, and you can either complete or reject it. For example, if a user was assigned a task and completed it, you can complete the task to continue the build. Deployment Manager also sends you an email when there is a manual step in the pipeline. You can complete or reject a step either within the pipeline or through email.

Deployment Manager also generates a manual step if there are schema changes in the application package that the release manager must apply. For more information, see Schema changes in application packages.

To complete or reject a manual step within the pipeline, do the following steps:

  1. Click Deployment Manager in the Designer Studio footer.
  2. Click a pipeline.
  3. Right-click the manual step and select one of the following options:
    • Complete task: Resolve the task so that the build continues through the pipeline.
    • Reject task: Reject the task so that the build does not proceed.

To complete or reject a manual step from within an email, click either Accept or Reject.

Schema changes in application packages

If an application package that is to be deployed on candidate systems contains schema changes, the Pega Platform orchestration server checks the candidate system to verify that you have the required privileges to deploy the schema changes. One of the following results occurs:

  • If you have the appropriate privileges, schema changes are automatically applied to the candidate system, the application package is deployed to the candidate system, and the pipeline continues.
  • If you do not have the appropriate privileges, Deployment Manager generates an SQL file that lists the schema changes and sends it to your email address. It also creates a manual step, pausing the pipeline, so that you can apply the schema changes. After you complete the step, the pipeline continues. For more information about completing a step, see Completing or rejecting a manual step.

You can also configure settings to automatically deploy schema changes so that you do not have to manually apply them if you do not have privileges to do so. For more information, see Configuring settings to automatically deploy schema changes.

Configuring settings to automatically deploy schema changes

You can configure settings to automatically deploy schema changes that are in an application package that is to be deployed on candidate systems. Configure these settings so that you do not have to apply schema changes if you do not have the privileges to deploy them.

  1. On each candidate system on which to deploy schema changes, in Pega Platform, set the AutoDBSchemaChanges dynamic system setting to true to enable schema changes at the system level.
    1. In Designer Studio, search for AutoDBSchemaChanges.
    2. On the Settings tab, in the Value field, enter true.
    3. Click Save.
  2. Add the SchemaImport privilege to your access role to enable schema changes at the user level. For more information, see Specifying privileges for an Access or Role to Object rule.

These settings are applied sequentially. If the AutoDBSchemaChanges dynamic system setting is set to false, you cannot deploy schema changes, even if you have the SchemaImport privilege.

For more information about the database/AutoDBSchemaChanges dynamic system setting, see Importing rules and data by using a direct connection to the database.

Pausing a build

When you pause a build, the pipeline completes the task that it is running, and stops the build at the next step.

To pause a build, click the Pause button.

Performing actions on a build with errors

If a build has errors, the pipeline stops processing on it. You can do one of the following actions:

  • Ignore the current step and run the next step by clicking the Start button.
  • Restart the build at the current step, after fixing the errors, by clicking the Start button.
  • Roll back to an earlier build by clicking the Roll back buildRoll back build button button.

Viewing branch status

You can view the status of all the branches that are in your pipeline. For example, you can see whether a branch was merged in a build and when it was merged.

  1. Click Deployment Manager in the Designer Studio footer.
  2. Click a pipeline.
  3. Click Actions > View branches.

Viewing build logs

View logs for a build to see the completion status of operations, for example, when a build is moved to a new stage. You can change the logging level to control which events are displayed in the log. For example, you can change logging levels of your builds from INFO to DEBUG for troubleshooting purposes. For more information, see Logging Level Settings tool.

  1. Click Deployment Manager in the Designer Studio footer.
  2. Click a pipeline.
  3. Click the Gear icon for the build for which you want to view the log file.
  4. Click View log.

Viewing build reports

Build reports provide information about a specific build. You can view information such as the number of tasks that you configured on a build that have been completed and when each task started and ended.

  1. Click Deployment Manager in the Designer Studio footer.
  2. Click a pipeline.
  3. Click the Gear icon for the build for which you want to view the build report.
  4. Click View report.

Viewing reports for all builds

Reports provide a variety of information about all the builds in your pipeline. You can view the following key performance information (KPI):

  • Deployment Success - Percentage of deployments that are successfully deployed to production.
  • Deployment Frequency - Frequency of new deployments to production.
  • Deployment Speed - Average time taken to deploy to the build from when it was started to production.
  • Build frequency - Frequency at which new builds are started.
  • Failure rate - Average number of failures per build.

To view reports, do the following tasks:

  1. Click Deployment Manager in the Designer Studio footer.
  2. Click a pipeline.
  3. Click Actions >View reports.

Deleting an application pipeline

When you delete a pipeline, its associated application packages are not removed from the repositories that the pipeline is configured to use.

  1. In the Designer Studio footer, click Deployment Manager.
  2. Click the Delete icon for the pipeline that you want to delete.
  3. Click Submit.

Viewing, downloading, and deleting application packages in repositories

You can view, download, and delete application packages in repositories that are on the orchestration server.

If you are using Deployment Manager on Pega Cloud, application packages that you have deployed to cloud repositories are stored on Pega Cloud. To manage your cloud storage space, you can download and permanently delete the packages.

  1. In the Designer Studio footer, click Deployment Manager.
  2. Click the pipeline for which you want to download or delete packages.
  3. Click either Development Repository or Production Repository.
  4. Click Actions > Browse artifacts.
  5. To download an application package, click the package, and then save it to the appropriate location.
  6. To delete a package, select the check boxes for the packages that you want to delete and click Delete.

Have a question? Get answers now.

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

Did you find this content helpful?

Want to help us improve this content?

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