Using Deployment Manager 4.7.x
Use Deployment Manager to create continuous integration and delivery (CI/CD) pipelines, which automate tasks so that you can 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 deployments, branches that are to be merged, and reports that provide information about your DevOps environment such as key performance indicators (KPIs).
For more information about using Deployment Manager and data migration pipelines, see Automatically exporting and importing simulation data with Deployment Manager 4.7.x.
For more information about using Deployment Manager to configure and use CI/CD pipelines, see the following topics:
- Logging in to Deployment Manager
- Accessing Dev Studio
- Accessing API documentation
- Roles and users
- Deployment Manager notifications
- Configuring an application pipeline
- Filtering pipelines in the dashboard
- Accessing systems in your pipeline
- Starting deployments
- Troubleshooting issues with your pipeline
- Schema changes in application packages
- Completing or rejecting a manual step in a deployment
- Managing aged updates
- Pausing a deployment
- Archiving and activating a pipeline
- Disabling and enabling a pipeline
- Stopping a deployment
- Managing a deployment with errors
- Viewing merge requests
- Viewing deployment reports
- Viewing reports for all deployments
- Deleting an application pipeline
- Viewing, downloading and deleting application packages in repositories
- Accessing API documentation
Logging in to Deployment Manager
Deployment Manager provides a dedicated portal from which you can access features. To log in to Deployment Manager, on the orchestration server, enter the DMReleaseAdmin operator ID and the password that you specified for it.
Accessing the Dev Studio portal
If your role has the appropriate permission, you can access the Dev Studio portal by by clicking Operator icon > Switch to Dev Studio. You can also open, modify, and create repositories and authentication profiles.
For more information on enabling a role to access Dev Studio, see Providing access to the Dev Studio portal.
Accessing API documentation
Deployment manager provides REST APIs for interacting with many resources in the Deployment Manager interface. Use these APIs to create and manage pipelines by using automated scripts or external information.
To access API documentation, open the Documentation/readme-for-swagger.md file in the DeploymentManager04_07_0x.zip file.
Roles and users
Deployment Manager provides two default roles, which you cannot modify or delete, that define privileges for super administrators and application administrators. Privileges for super administrators are applied across all applications, and privileges for application administrators are applied to specific applications.
Super administrators can also add roles and specify the privileges to assign to them. Super administrators and application administrators can add users and assign them access to the applications that they manage. By defining roles and users, you can manage which users can access Deployment Manager and which features they can access. For example, you can create a role that does not permit users to delete pipelines for a specific application.
For more information, see the following topics:
- Using roles and privileges by creating a dynamic system setting
- Adding and modifying roles
- Adding users and specifying their roles
- Providing access to the Dev Studio portal
- Modifying user roles and privileges
- Modifying your user details and password
- Deleting users
Using roles and privileges by creating a dynamic system setting
To use roles and privileges, you must first create the EnableAttributeBasedSecurity dynamic system setting.
- In Dev Studio, click Create > SysAdmin > Dynamic System Settings.
- In the Short Description field, enter a short description.
- In the Owning Ruleset field, enter Pega-RulesEngine.
- In the Setting Purpose field, enter EnableAttributeBasedSecurity.
- Click Create and open.
- On the Settings tab, in the value field, enter true.
- Click Save.
Adding and modifying roles
If you are a super administrator, you can add and modify roles. Users within a role share defined responsibilities such as starting a pipeline.
To add and modify roles, perform the following steps:
- In the navigation pane of Deployment Manager, click Users, and then click Roles and privileges.
- Do one of the following actions:
- To add a role, click Add role.
- To modify a role, click a role, and then click Edit.
- In the Add role or Edit role dialog box, in the Namefield, enter a name for the role.
- Select the privileges that you want to assign to the role.
- Click Submit.
Providing access to the Dev Studio portal
Deployment Manager provides a dedicated portal from which you can access features. In addition, if you have permission to use the Dev Studio portal, you can open, modify, and create repositories and authentication profiles in Dev Studio from within the Deployment Manager portal.
To provide access to the Dev Studio portal for a role, complete the following steps:
- In the navigation pane of Deployment Manager, click Users, and then click Roles and privileges.
- Do one of the following actions:
- To add a role, click Add role.
- To modify a role, click Edit.
- In the Add role or Edit Role dialog box, in the Name field, enter the name of the role.
- Click Access to Dev Studio.
- Click Submit.
Adding users and specifying their roles
If you are a super administrator or application administrator, you can add users to Deployment Manager and specify their roles.
Only super administrators can create other super administrators or application administrators who can access one or more applications. Application administrators can create other application administrators for the applications that they manage.
- In the navigation pane of Deployment Manager, click Users, and then click People.
- On the People page, click Add user.
- In the Add user dialog box, click the User field, and do one of the following actions:
- Press the Down arrow key and select the user that you want to add.
- Enter an email address.
- Click Add.
- From the Role list, select the role to assign to the user.
- Optional: If you selected the App admin role or a custom role, in the Applications field, enter the application name that the user can access.
- Click Send invite to send an email, which contains the user name and a randomly generated password for the user to log in to Deployment Manager with, to the user.
Modifying user roles and privileges
Super administrators can give other users super administrative privileges or assign them as application administrators to any application. Application administrators can assign other users as application administrators for the applications that they manage.
- In the navigation pane of Deployment Manager, click Users, and then click People.
- On the People page, click the user.
- In the Roles and privileges section, modify the user role and applications that they can access, as appropriate.
- Click Save.
Modifying your user details and password
You can modify your own user details, such as first and last name, and you can change your password.
To update your information, perform the following steps:
- In the navigation pane of Deployment Manager, click Users, and then click People.
- On the People page, click your user name.
- In the Personal details section, modify your name, email address, and phone number, as appropriate.
- To change your password:
- Click Update password.
- In the Change operator ID dialog box, enter your new password, reenter it to confirm it, and then click Submit.
- Click Save.
Deleting users
If you are a super administrator or application administrator, you can delete users for the applications that you manage.
To delete users, perform the following steps:
- In the navigation pane of Deployment Manager, click Users, and then click People.
- On the People page, click the Delete icon for the user that you want to delete.
Deployment Manager notifications
You can enable notifications to receive updates about the events that occur in your pipeline. For example, you can choose to receive emails about whether Pega unit tests failed or succeeded. You can receive notifications in the Deployment Manager notifications gadget, through email, or both. By default, all notifications are enabled for users who are configured in Deployment Manager.
See the following topics for more information:
- Managing Deployment Manager notifications
- Configuring email senders and recipients
- Adding custom Deployment Manager notification channels
Managing Deployment Manager notifications
To enable notifications and select the notifications that you want to receive, perform the following actions:
- In the Deployment Manager navigation pane, click your profile icon.
- Click Notification preferences.
- Select the events for which you want to receive notifications.
- Specify how you want to receive notifications.
- Click Submit.
Viewing and updating email account information for notifications
Receiving email notifications requires that an email account is configured on the orchestration server. You can view and update your email settings in Deployment Manager.
Changing your email settings requires access to Dev Studio, so your user role must have permission to access Dev Studio. For more information, see Roles and users.
- In the navigation pane of Deployment Manager, click .
- To update your email settings, do the following steps:
- At the top of the Settings: Email configuration page, click Dev Studio.
- In the Edit Email Account rule form, configure and save the email account.
- In the bottom left corner of Dev Studio, click Back to Deployment Manager to return to the Deployment Manager portal.
- Click the Refresh icon to refresh your email configuration. information
Adding custom Deployment Manager notification channels
You can receive notifications through email, the Deployment Manager notifications gadget, or both. You can create custom notification channels to meet application requirements such as sending notifications as phone text messages or as push notifications on mobile devices.
Deployment Manager provides the following notifications to which you can add channels:
- pyAbortDeployment
- pyTaskFailure
- pyTaskFailure
- pyTaskCompletion
- pyStartDeployment
- pyStageCompletion
- pySchemaChange
- pyDeploymentCompletion
- pyAgedUpdateActionTaken
- pyAgedUpdateActionRequired
To create a custom notification channel, complete the following steps:
- On the orchestration server, in Pega Platform, create a custom notification channel. For more information, see Adding a custom notification channel.
- Add the application ruleset, which contains the channel that you created, to the Deployment Manager application.
- In the Dev Studio header, click Deployment Manager, and then click Definition.
- On the Edit Application rule form, in the Application rulesets section, click Add ruleset.
- Press the Down arrow key and select the ruleset and version that contains the custom notification channel.
- Save the rule form.
- Enable the channel that you created on the appropriate notifications by savin the notification in the application ruleset that contains the channel.
For example, if you want to use the Mobile channel for the pyStartDeployment notification, save the pyStartDeployment notification in the application ruleset that contains the Mobile channel. - Enable the channel on the notification.
- Open the notification by clicking , and then clicking the notification.
- Click the Channels tab.
- On the Channel configurations page, select the channel that you want to use.
- Save the rule form.
Configuring an application pipeline
When you add a pipeline, you specify merge criteria and configure stages and steps in the continuous delivery workflow. 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 must be 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:
- To move a deployment 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.
- To use parallel development and hotfix life cycles for your application.
Your user role determines if you can create a pipeline. For more information about user roles, see Roles and users.
For more information, see the following topics:
- Adding a pipeline on Pega Cloud Services
- Adding a pipeline on premises
- Modifying application details
- Modifying URLs and authentication profiles
- Modifying development and production repositories
- Specifying Jenkins server information
- Specifying merge options for branches
- Modifying stages and tasks in the pipeline
Adding a pipeline on Pega Cloud Services
To add a pipeline on Pega Cloud Services, perform the following steps:
- Click .
- Click New.
- Specify the details of the application for which you are creating the pipeline.
- Optional: To change the URL of your development system, which is populated by default with your development system URL, in the Development environment field, press the Down arrow key and select the URL.
This is the system on which the product rule that defines the application package that moves through the repository is located. - In the Application field, press the Down arrow key and select the name of the application.
- In the Version field, press the Down arrow key and select the application version.
- Click the Access group field and select the access group for which pipeline tasks are run. This access group must be present on all the candidate systems and have at least the sysadmin4 role. Ensure that the access group is correctly pointing to the application name and version that is configured in the pipeline.
- In the Pipeline name field, enter the name of the pipeline. This name must be unique.
- Optional: To change product rule that defines the contents of the application, the Product rule field, enter the name of the product rule that defines the contents of the application, which is populated by default with the application name.
- Optional: To change the product rule version, in Version field, enter the version, which is populated by default with the application version.
- Optional: To change the URL of your development system, which is populated by default with your development system URL, in the Development environment field, press the Down arrow key and select the URL.
- If you are using a separate product rule to manage test cases, in the Application test cases section, to deploy a test case, select the Deploy test applications check box; then, complete the following steps:
- In the Test application field, enter the name of the test application.
- In the Version field, enter the version of the test case product rule.
- In the Access group field, enter the access group for which test cases are run.
- In the Product rule field, enter the name of the test case product rule.
- From the Deploy until field, select the pipeline stage until which the test case product rule will be deployed.
- Click Create.
The system adds tasks, which you cannot delete, to the pipeline that are required to successfully run a workflow, for example, Deploy and Generate Artifact. For Pega Cloud Services, it also adds mandatory tasks that must be run on the pipeline, for example, the Check guardrail compliance task and Verify security checklist task.
- Optional: Add tasks that you want to perform on your pipeline, such as Pega unit testing. For more information, see Modifying stages and tasks in the pipeline.
Adding a pipeline on premises
To add a pipeline on premises, complete the following steps:
- Click .
- Click .
- Specify the details of the application for which you are creating the pipeline.
- In the Development environment field, enter the URL of the development system. This is the system on which the product rule that defines the application package that moves through the repository is located.
- In the Application field, press the Down arrow key and select the name of the application.
- In the Version field, press the Down arrow key and select the application version.
- In the Access group field, press the Down arrow key and select the access group for which pipeline tasks are run. This access group must be present on all the candidate systems and have at least the sysadmin4 role.
- In the Pipeline name field, enter the name of the pipeline. This name must be unique.
- In the Product rule field, enter the name of the product rule that defines the contents of the application.
- In the Version field, enter the product rule version.
- If you are using a separate product rule to manage test cases, in the Application test cases section, to deploy a test case, select the Deploy test applications check box; then, complete the following steps:
- In the Test application field, enter the name of the test application.
- In the Version field, enter the version of the test case product rule.
- In the Access group field, enter the access group for which test cases are run. Ensure that the access group is correctly pointing to the application name and version that is configured in the pipeline.
- In the Product rule field, enter the name of the test case product rule.
- From the Deploy until field, select the pipeline stage until which the test case product rule will be deployed.
- Click Dependencies.
- Click Add.
- In the Application name field, press the Down arrow key and select the application name.
- In the Application version field, press the Down arrow key and select the application version.
- In the Repository name field, press the Down arrow key and select the repository that contains the production-ready artifact of the dependent application. If you want the latest artifact of the dependent application to be automatically populated, ensure that the repository that contains the production-ready artifact of the dependent application is configured to support file updates.
- In the Artifact name field, press the Down arrow key and select the artifact.
For more information about dependent applications, see Listing product dependencies.
- Click Next.
- In the Environment details section, in the Stages section, specify the URL of each candidate system and the authentication profile that each system uses to communicate with the orchestration system.
- In the Environments field for the system, press the Down arrow key and select the URL of the system.
- Optional: If you are using your own authentication profiles, in the Authentication field for the system, press the Down arrow key and select the authentication profile that you want to communicate from the orchestration server to the system.
By default, the fields are populated with the DMAppAdmin authentication profile.
- In theArtifact management section, specify the development and production repositories through which the product rule that contains application contents moves through the pipeline.
- In the Development repository field, press the Down arrow key and select the development repository.
- In the Production repository field, press the Down arrow key and select the production repository.
- Optional: In the External orchestrationserver section, if you are using a Run Jenkins step task in a pipeline, specify the Jenkins details.
- In the URLfield, enter the URL of the Jenkins server.
- 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.
- Click Next.
- Specify whether you are using branches in your application:
- If you are not using branches, click the No radio button, and then go to step 15.
- If you are using branches, go to the next step.
- Configure branch settings:
- Click the Yes radio button.
- Do one of the following actions:
- To merge branches into the highest existing ruleset in the application, click .
- To merge branches into a new ruleset, click .
- In the Password field, enter the password that locks the rulesets on the development system.
- Click Next.
The system adds tasks, which you cannot delete, to the pipeline that are required to successfully run a workflow, for example, Deploy and Generate Artifact. The system also adds other tasks to enforce best practices such as Check guardrail compliance and Verify security checklist.
- Optional: To specify that a branch must meet a compliance score before it can be merged:
- In the Merge criteria pane, click Add task.
- From the Task list, select Check guardrail compliance.
- In the Weighted compliance score field, enter the minimum required compliance score.
- Click Submit. For more information about compliance scores, see Compliance score logic.
- Optional: To specify that a branch must meet a compliance score before it can be merged:
- In the Merge criteria pane, click Add task.
- From the Task list, select Check review status.
- Click Submit. For more information about branch reviews, see Branch reviews.
- Optional: To run Pega unit tests on the branches for the pipeline application or for an application that is associated with an access group before it can be merged:
- In the Merge criteria pane, click Add task.
- From the Task list, select Pega unit testing.
- Optional: To run all the Pega unit tests for an application that is associated with an access group, in the Access Group field, enter the access group.
- Click Submit. For more information about creating Pega unit tests, see Creating Pega unit test cases.
- Optional: To start a deployment automatically when a branch is merged, click the Trigger deployment on merge check box. Do not select this check box if you want to manually start deployments. For more information, see Manually starting a deployment.
- Optional: Clear a check box for a deployment life cycle stage to skip it.
- Optional: In the Continuous Deployment section, specify the tasks to be performed during each stage of the pipeline.See the following topics for more information:
- Running Pega unit tests by adding the Pega unit testing task
- Run Jenkins steps by adding the the Run Jenkins step task
- Continuing or stopping a deployment by adding the Perform manual step task
- Specifying that an application meet a compliance score by adding Check guardrail compliance task
- Ensuring that the Application Security Checklist is completed by adding the Verify security checklist task
- Starting test coverage by adding the Enable test coverage task
- Stopping test coverage by adding the Validate test coverage task
- Running scenario tests by adding the Run Pega scenario tests task
- Refreshing the Application Quality dashboard by adding the Refresh application quality task
- Starting another pipeline by adding the Trigger deployment task
- Modifying the Approve for production task
- 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.
- Click Finish.
Running Pega unit tests by adding the Run Pega unit tests task
When you use separate product rules for test cases and run a pipeline, the Pega unit testing task is run for the access group that is specified in the Application test cases section, which you configure when you add or modify a pipeline.
To add a Run Pega unit test task, do the following steps:
- Do one of the following actions:
- Click a task, click the Moreicon, and then click either Add task above or Add task below.
- Click Add task in the stage.
- To run Pega unit tests for either the pipeline application or for an application that is associated with an access group, select Pega unit testing fromthe Task list.
- Do one of the following actions:
- Optional: To run all the Pega unit tests that are in a Pega unit suite for the pipeline application, in the Test Suite ID field, enter the pxInsName of the test suite.
You can find this value in the XML document that comprises the test suite by clicking, in Pega Platform, Actions > XML on the Edit Test Suite form. If you do not specify a test suite, all the Pega unit tests for the pipeline application are run.
- Optional: To run all the Pega unit tests for an application that is associated with an access group, in the Access Group field, enter the access group.
For more information about creating Pega unit tests, see Creating Pega unit test cases.
- Optional: To run all the Pega unit tests that are in a Pega unit suite for the pipeline application, in the Test Suite ID field, enter the pxInsName of the test suite.
- Click Submit.
- Continue configuring your pipeline. For more information, see one of the following topics:
Running Jenkins steps by adding the Run Jenkins step task
If you are using Jenkins to perform tasks in your pipeline, you can add the Run Jenkins step to the stage on which you want it to run. If you have configured the Jenkins OrchestratorURL and PipelineID parameters, when this task fails, the pipeline stops running.
To add a Run Jenkins step ask, perform the following steps:
- Do one of the following actions:
- Click a manually added task, click the Moreicon, and then click either Add task above or Add task below.
- Click Add task in the stage.
- In the Job name field, enter the name of the Jenkins job (which is the name of the Jenkins deployment) that you want to run.
- In the Token field, enter the Jenkins authentication token.
- In the Parameters field, enter parameters, if any, to send to the Jenkins job.
- Click Submit.
- Continue configuring your pipeline. For more information, see one of the following topics:
Completing or stopping a deployment by adding the Perform manual step task
Use manual steps so that users must take an action before a pipeline deployment can continue. Users can either accept the task to continue the deployment or reject the task to stop it.
To add a manual step that a user must perform in the pipeline, do the following steps:
- Do one of the following actions:
- Click a manually added task, click the Moreicon, and then click either Add task above or Add task below.
- Click Add task in the stage.
- From the Task list, select Manual.
- In the Job name field, enter text that describes the action that you want the user to take.
- In the Assigned to field, press the Down arrow key and select the operator ID to assign the task to.
- Click Submit.
- Continue configuring your pipeline. For more information, see one of the following topics:
Adding the Check guardrail compliance score task
You can use the Check guardrail compliance score task so that an application must meet a compliance score for the deployment to continue. The default value is 97, which you can modify.
To specify that an application must meet a compliance score, do the following steps:
- Do one of the following actions:
- Click a manually added task, click the Moreicon, and then click either Add task above or Add task below.
- Click Add task in the stage.
- From the Task list, select Check guardrail compliance.
- In the Weighted compliance score field, enter the minimum required compliance score.
- Continue configuring your pipeline. For more information, see one of the following topics:
Adding the Verify security checklist task
For your pipeline to comply with security best practices, you can add a task so that to ensure that all the steps in Application Security Checklist are performed.
To add the Verify security checklist task, perform the following steps:
- Do one of the following actions:
- Click a manually added task, click the Moreicon, and then click either Add task above or Add task below.
- Click Add task in the stage.
- From the Task list, select Verify Security checklist.
- Click Submit.
- Continue configuring your pipeline. For more information, see one of the following topics:
Starting test coverage by adding the Enable test coverage task
Add the Enable test coverage task to start test coverage. Starting and stopping test coverage generates a report that identifies the executable rules in your application that are either covered or not covered by tests. As a best practice, to ensure application quality, you should test all the rules in your application for which testing is supported.
When you use separate product rules for test cases and run a pipeline, the Enable test coverage task is run for the access group that is specified in the Application test cases section, which you configure when you add or modify a pipeline.
To add the Enable test coverage task, perform the following steps:
- Do one of the following actions:
- Click a manually added task, click the Moreicon, and then click either Add task above or Add task below.
- Click Add task in the stage.
- From the Task list, select Enable test coverage.
- Select the Start a new session check box to start a test coverage session every time that the pipeline runs the deployment. If you do not select this check box, if a test coverage session is already running, the pipeline pauses and returns an error.
- Click Submit.
- Continue configuring your pipeline. For more information, see one of the following topics:
Stopping test coverage by adding the Validate test coverage step
To stop a test coverage session, addthis task below the Enable test coverage task on the same system. You must add this task to stop a test coverage session if you used the Enable test coverage task. For more information about application-level coverage reports, see Generating an application-level test coverage report.
When you use separate product rules for test cases and run a pipeline, the Validate test coverage task is run for the access group that is specified in the Application test cases section, which you configure when you add or modify a pipeline.
To add the Validate test coverage step, perform the following actions:
- Do one of the following actions:
- Click a manually added task, click the Moreicon, and then click either Add task above or Add task below.
- Click Add task in the stage.
- From the Task list, select Validate test coverage.
- Click Submit.
- Continue configuring your pipeline. For more information, see one of the following topics:
Running scenario tests by adding the Run Pega scenario tests step
If you are using Pega scenario tasks, you can run them in your pipeline by using the Run Pega scenario tests task. For more information about scenario tests, see Creating a scenario test. Deployment Manager supports Selenium 3.141.59.
To add the Run Pega scenario tests task, do the following steps:
- Do one of the following actions:
- Click a manually added task, click the Moreicon, and then click either Add task above or Add task below.
- Click Add task in the stage.
- From the Task list, select Run Pega scenario tests.
- In the User name field, enter the user name for the Pega Platform instance on which you are running scenario tests. For the Run Pega scenario tests task, if you are using a separate product rule for a test application, the user name that you provide should belong to the access group that is associated with the test application.
- In the Password field, enter the Pega Platform password.
- From the Test Service Provider field, select the browser that you are using to run the scenario tests in the pipeline.
- Do one of the following actions:
- If you selected CrossBrowserTesting, BrowserStack, or SauceLabs:
- In the Provider auth name field, enter the auth name that you you use to log in to the test service provider.
- In the Provider auth key field, enter the key for the test service provider.
- Go to step 9.
- If you selected Standalone, in the Provider URL field, enter the URL of the Selenium Standalone Server by using one of the following:
- Hub hostname and port: Use the format Hubhostname:port.
- IP address: Enclose the IP address in double quotation marks.
- In the Browser field, enter the browser that you are using to record scenario tests.
- In the Browserversion field, enter the browser version.
- In the Platform field, enter the development platform that you are using to record tests.
- In the Screen resolution field, enter the resolution at which are recording scenario tests.
- Click Submit.
- Continue configuring your pipeline. For more information, see one of the following topics:
Adding the Refresh application quality task
To refresh the Application Quality dashboard, which provides information about the health of your application, on the candidate system, add the Refresh application quality task. You can add this task to refresh the dashboard after running Pega unit tests, checking guardrail compliance, running Pega scenario tests, and starting or stopping test coverage.
- Do one of the following actions:
- Click a manually added task, click the Moreicon, and then click either Add task above or Add task below.
- Click Add task in the stage.
- From the Task list, select Refresh application quality.
- Click Submit.
- Continue configuring your pipeline. For more information, see one of the following topics:
Starting another pipeline by adding the Trigger deployment task
You can start another pipeline by adding the Trigger deployment task to a stage in your current pipeline. By starting another pipeline from a current pipeline, you can add more stages to your pipeline.
To add the Trigger deployment task, do the following steps:
- Do one of the following actions:
- Click a task, click the More icon, and then click either Add task above or Add task below.
- Click Add task in the stage.
- In the Task list, click Trigger deployment.
- In the Application name field, press the Down arrow key and select the application that you want to deploy.
- In the Pipeline name field, press the Down arrow key and select the pipeline that you want to start.
- If you want to deploy the artifact that you are deploying in the current pipeline, select the Deploy current artifact check box. Otherwise, a new application is deployed on the pipeine.
- Click Submit.
Modifying the Approve for production task
To modify the Approve for production task, which is added to the stage before production and which you use so that a user must approve application changes before they are sent to production, do the following steps:
- Click the Info icon.
- In the Job name field, enter a name for the task.
- In the Assign to field, press the Down arrow key and select the user who approves the application for production. An email is sent to this user, who can approve or reject application changes from within the email.
- Click Submit.
- Continue configuring your pipeline. For more information, see one of the following topics:
Modifying application details
You can modify application details, such as the product rule that defines the content of the application that moves through the pipeline.
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Click Actions > Pipeline settings.
- Click Application details.
- Optional: In the Development environment field, enter the URL of the development system, which is the system on which the product rule that defines the application package that moves through the repository is located.
- Optional: In the Version field, press the Down arrow key and select the application version.
- Optional: In the Product rule field, enter the product rule that defines the contents of the application.
- Optional: In the Version field, enter the product rule version.
- f you are using a separate product rule to manage test cases, in the Application test cases section, complete the following steps:
- To deploy test cases, select the Deploy test applications check box.
- In the Test application field, enter the name of the test application.
- In the Version field, enter the version of the test case product rule.
- In the Access group field, enter the access group for which test cases are run.
- In the Product rule field, enter the name of the test case product rule.
- From the Deploy until field, select the pipeline stage until which the test case product rule will be deployed.
- Optional: If the application depends on other applications, in the Dependencies section, add those applications.
- Click Add.
- In the Application name field, press the Down arrow key and select the application name.
- In the Application version field, press the Down arrow key and select the application version.
- In the Repository name field, press the Down arrow key and select the repository that contains the production-ready artifact of the dependent application. If you want the latest artifact of the dependent application to be automatically populated, ensure that the repository that contains the production-ready artifact of the dependent application is configured to support file updates.
- In the Artifact name field, press the Down arrow key and select the artifact.
For more information about dependent applications, see Listing product dependencies.
Modifying URLs and authentication profiles
You can modify the URLs of your development and candidate systems and the authentication profiles that are used to communicate between those systems and the orchestration server.
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Click Actions > Pipeline settings.
- Click Deployment stages.
- In the Environments field for the system, press the Down arrow key and select the URL of the system.
- In the Authentication field for the system, press the Down arrow key and select the authentication profile that you want to communicate from the orchestration server to the system.
- Click Save.
Modifying development and production repositories
You can modify the development and production repositories through which the product rule that contains application contents moves through the pipeline. All the generated artifacts are archived in the Development repository, and all the production-ready artifacts are archived in the Production repository.
You do not need to configure repositories if you are using Pega Cloud Services; you can use different repositories other than the default ones that are provided.
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Click Actions > Pipeline settings.
- Click Artifact Management.
- If you are using Deployment Manager on premises, or on Pega Cloud Services with default repositories, complete the following tasks:
- In the Application repository section, in the Development repository field, press the Down arrow key and select the development repository
- In the Production repository field, press the Down arrow key and select the production repository.
- If you are using Deployment Manager on Pega Cloud Services and want to use different repositories other than the default repositories, complete the following tasks:
- In the Artifact repository section, click Yes.
- In the Development repository field, press the Down arrow key and select the development repository.
- In the Production repository field, press the Down arrow key and select the production repository.
- Click Save.
Specifying Jenkins server information
If you are using a Run Jenkins step task, specify details about the Jenkins server such as its URL.
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Click Actions > Pipeline settings.
- Click External orchestration server.
- In the URL field, enter the URL of the Jenkins server.
- 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.
- Click Save.
Specifying merge options for branches
If you are using branches in your application, specify options for merging branches into the base application.
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Click Actions > Pipeline settings.
- Click Merge policy.
- If you are not using branches, click the No radio button, and then go to step 6.
- If you are using branches, do the following actions:
- Click Yes.
- Do one of the following actions:
- To merge branches into the highest existing ruleset in the application, click .
- To merge branches into a new ruleset, click .
- In the Password field, enter the password that locks the rulesets on the development system.
- Click Save.
Modifying stages and tasks in the pipeline
You can modify the stages and the tasks that are performed in each stage of the pipeline. For example, you can skip a stage or add tasks such as Pega unit testing to be done on the QA stage.
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Click Pipeline model.
- Optional: To specify that a branch must meet a compliance score before it can be merged:
- In the Merge criteria pane, click Add task.
- From the Task list, select Check guardrail compliance.
- In the Weighted compliance score field, enter the minimum required compliance score.
- Click Submit. For more information about compliance scores, see Compliance score logic.
- Optional: To specify that a branch must meet a compliance score before it can be merged:
- In the Merge criteria pane, click Add task.
- From the Task list, select Check review status.
- Click Submit. For more information about branch reviews, see Branch reviews.
- Optional: To run Pega unit tests on the branches for the pipeline application or for an application that is associated with an access group before it can be merged:
- In the Merge criteria pane, click Add task.
- From the Task list, select Pega unit testing.
- Optional: To run all the Pega unit tests for an application that is associated with an access group, in the Access Group field, enter the access group.
- Click Submit. For more information about creating Pega unit tests, see Creating Pega unit test cases.
- Optional: To start a deployment automatically when a branch is merged, select the Trigger deployment on merge check box. Do not select this check box if you want to manually start a deployment. For more information, see Manually starting a deployment.
- Optional: Clear a check box for a deployment life cycle stage to skip it.
- Optional: In the Continuous Deployment section, specify the tasks to be performed during each stage of the pipeline. See the following topics for more information:
- Running Pega unit tests by adding the Pega unit testing task
- Run Jenkins steps by adding the the Run Jenkins step task
- Continuing or stopping a deployment by adding the Perform manual step task
- Specifying that an application meet a compliance score by adding Check guardrail compliance task
- Ensuring that the Application Security Checklist is completed by adding the Verify security checklist task
- Starting test coverage by adding the Enable test coverage task
- Stopping test coverage by adding the Validate test coverage task
- Running scenario tests by adding the Run Pega scenario tests task
- Refreshing the Application Quality dashboard by adding the Refresh application quality task
- Starting another pipeline by adding the Trigger deployment task
- Modifying the Approve for production task
- 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.
- Click Finish.
Filtering pipelines in the dashboard
You can filter the pipelines that the dashboard displays by application name, version, and pipeline deployment status. Filter pipelines so that the dashboard displays only the information that is relevant to you.
To filter pipelines, perform the following steps:
- Click .
- At the top of the dashboard, in the View lists, select the information with which you want to filter pipelines, and then click Apply.
Accessing systems in your pipeline
You can open the systems in your pipeline and log in to the Pega Platform instances.
- If the pipeline is not already open, in the navigation pane of Deployment Manager, click .
- Click the pop-out arrow for the system that you want to open.
Starting deployments
You can start deployments in a number of ways. For example, you can start a deployment manually if you are not using branches, by submitting a branch into the Merge Branches wizard, or by publishing application changes in App Studio to create a patch version of your application. See the following topics for more information:
- Manually starting a deployment
- Starting a deployment by using the Merge Branches wizard
- Publishing application changes in App Studio
Your user role determines if you can start a deployment. For more information about user roles, see Roles and users.
Manually starting a deployment
You can start a deployment manually if you are not using branches and are working directly in rulesets.
You can also start a deployment manually if you do not want deployments to start automatically when branches are merged. You must also clear the Trigger deployment on merge check box in the pipeline configuration.
- Do one of the following actions:
- If the pipeline that you want to start is open, click Start deployment.
- Click Start deployment for the pipeline that you want to start. , and then click
- In the Start deployment dialog box, start a new deployment or deploy an existing application by completing one of the following actions:
- To start a deployment and deploy a new application package, do the following steps:
- Click .
- In the Deployment name field, enter the name of the deployment.
- Click Deploy.
- To deploy an application package that is on a cloud repository, do the following steps:
- Click .
- In the Deployment name field, enter the name of the deployment.
- In the Select a repository field, press the Down arrow key and select the repository.
- In the Select an artifact field, press the Down arrow key and select the application package.
- To start a deployment and deploy a new application package, do the following steps:
- Click Deploy.
Starting a deployment by using the Merge Branches wizard
In either a branch-based or distributed, branch-based environment, you can immediately start a deployment by submitting a branch into a pipeline in the Merge Branches wizard. The wizard displays the merge status of branches so that you do not need to open Deployment Manager to view it.
If you are using a separate product rule for a test application, after you start a deployment either by using the Merge Branches wizard, the branches of both the target and test applications are merged in the pipeline.
Prerequisites
You can submit a branch to your application and start the continuous integration portion of the pipeline when the following criteria is met:
- You have created a pipeline for your application in Deployment Manager.
- You are merging a single branch.
- The RMURL dynamic system setting, which defines the URL of orchestration server, is configured on the system.
- All the rulesets in your branch belong to a single application that is associated with your pipeline. Therefore, your branch cannot contain rulesets that belong to different application layers.
Before you merge branches, do the following tasks:
- Check all rules into their base rulesets before you merge them.
- Check if there are any potential conflicts to address before mergingbranches. For more information, see Viewing branch information.
- As a best practice, lock a branch after development is complete so that no more changes can be made. For more information, see Locking a branch.
- Check if there are any potential conflicts to address before mergingbranches. For more information, see Viewing branch information.
Submitting a branch into an application by using the Merge Branches wizard
To submit a branch into an application by using the Merge Branches wizard, perform the following steps:
- In the navigation pane in Dev Studio, click App, and then click Branches.
- Right-click the branch and click .
- Click Proceed.
- The wizard displays a message in the following scenarios:
- If there are no pipelines that are configured for your application or there are no branches in the target application.
- If the value for the RMURL dynamic system setting is not valid.
You can click Switch to standard merge to switch to the Merge Branches wizard that you can use to merge branches into target rulesets. For more information, see Merging branches into target rulesets.
- In the Application pipelines section, from the Pipeline list, select the application for which the pipeline is configured into which you want to merge branches.
- In the Merge Description field, enter information that you want to capture about the merge.
This information appears when you view deployment details.
- In the Associated User stories/bugs field, press the Down arrow key, and then select the Agile Workbench user story or bug that you want to associate with this branch merge.
This information appears when you view deployment details.
- Click Merge.
The system queues the branch for merging, generates a case ID for the merge, and runs the continuous integration criteria that you specified.
If there are errors, and the merge is not successful, an email is sent to the operator ID of the release manager that is specified on the orchestration server.
The branch is stored in the development repository and, after the merge is completed, Deployment Manager deletes the branch from the development system. By storing branches in the development repository, Deployment Manager keeps a history, which you can view, of the branches in a centralized location.
If your development system is appropriately configured, you can rebase your development application to obtain the most recently committed rulesets after you merge your branches. For more information, see Rebasing rules to obtain latest versions.
Publishing application changes in App Studio
You can publish application changes that you make in App Studio to the pipeline. Publishing your changes creates a patch version of the application and starts a deployment. For example, you can change a life cycle, data model, or user interface elements in a screen and submit those changes to systems in the pipeline.
When you publish an application to a stage, your rules are deployed immediately to that system. To allow stakeholders to inspect and verify changes before they are deployed the stage, configure a manual task in on the previous stage. When the pipeline runs, it is paused during a manual step that is assigned to a user, which allows stakeholders to review your changes before they approve the step and resume running the pipeline.
If you do not have a product rule for the pipeline application, you must create one that has the same name and version as the pipeline application. For more information, see Creating a product rule by using the create menu.
- In App Studio, do one of the following actions:
- Click Turn editing on, and then, in the navigation pane of Deployment Manager, click Settings > Versions.
- In the App Studio header, click Publish.
The Settings page displays the stages that are enabled in the application pipeline in Deployment Manager. The available stages are, in order, quality assurance, staging, and production.
It also displays the application versions that are on each system. The version numbers are taken from the number at the end of each application deployment name in Deployment Manager. For example, if a deployment has a name of "MyNewApp:01_01_75", the page displays "v75".
- Submit an application from development to quality assurance or staging in your pipeline by completing the following steps:
- Click either Publish to QA or Publish to staging.
- Optional:To add a comment, which will be published when you submit the application, add a comment in the Publish confirmation dialog box.
- Optional:If Agile Workbench has been configured, to associate a bug or user story with the application, in the Associated User stories/Bugs field, press the Down arrow key and select the bug or user story.
- Click OK.
Each unlocked ruleset version in your application is locked and rolled to the next highest version and is packaged and imported into the system. The amount of time that publishing application changes takes depends on the size of your application.
A new application is also copied from the application that is defined on the pipeline in Deployment Manager. The application patch version is updated to reflect the version of the new rulesets; for example, if the ruleset versions of the patch application are 01-01-15, the application version is updated to be 01.01.15. A new product rule is also created.
In addition, this application is locked and cannot be unlocked. You can use this application to test specific patch versions of your application on quality assurance or staging systems. You can also use it to roll back a deployment.
- Optional: Make changes to your application in the unlocked rulesets, which you can publish again into the pipeline. If an application is already on the system, it is overridden by the new version that you publish.
- Optional:If you configured a manual step, request that stakeholders review and test your changes. After they communicate to you that they have completed testing, you can publish your changes to the next stage in the pipeline.
- Publish the application to the next stage in the pipeline by clicking the link that is displayed. The name of the link is the Job name field of the manual task that is defined on the stage.
Troubleshooting issues with your pipeline
Deployment Manager provides several features that help you troubleshoot and resolve issues with your pipeline. You can:
- View deployment logs for information about the completion status of operations.
- Run diagnostics to verify that your environment is correctly configured.
- Stop all deployments that are running on a pipeline.
- Use a chatbot to obtain information about common issues.
See the following topics for more information:
- Viewing deployment logs for a specific deployment
- Diagnosing a pipeline
- Stopping all deployments
- Obtaining information about common issues by using a chatbot
Viewing deployment logs for a specific deployment
View logs for a deployment to see the completion status of operations, for example, when a deployment moves to the QA stage on a pipeline.
When the Deploy task runs, the application package is imported in to the candidate system. By default, logs record all the new rule and data instances and all the updated rule and data instances that are in this application package. You can disable the logging of such rule and data types.
To view a deployment log, complete the following steps:
- Optional: In Dev Studio, on the appropriate candidate system, change the logging level to control which events the log displays.
For example, you can change the logging levels of your deployment from INFO to DEBUG for troubleshooting purposes. For more information, see Logging Level Settings tool.
- Optional: To disable logging of new and updated rule and data instances in imported application packages, perform the following steps:
- On the candidate system for which you want to disable reporting, in the navigation pane of Admin Studio, click .
- On the Log categories page, for the DeploymentManager.DeltaInstanceLogging log level, click the More icon, and then click Change logging level.
- In the Change pxBackgroundProcessing.Agents log level dialog box, in the Update log level of category to list, select OFF.
- Click .
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Perform one of the following actions:
- To view the log for the current deployment, click the More icon, and then click View logs.
- To view the log for a previous deployment, expand the Deployment History pane and click Logs for the appropriate deployment.
Diagnosing a pipeline
You can diagnose your pipeline to verify that your pipeline is configured properly such as whether the target application and product rule are in the development environment, connectivity between systems and repositories is working, and pre-merge settings are correctly configured.
To diagnose a pipeline, perform the following steps:
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Click .
- In the Diagnostics window, review the errors, if any.
Stopping all deployments
You can stop all the deployments on a pipeline at once to quickly troubleshoot issues and resolve failed pipelines.
Take the following steps to stop all deployments on a pipeline:
- If the pipeline is not open, in the navigation pane of Deployment Manager, click .
- Click .
- In the Abort open deployments dialog box, enter a reason for stopping the deployments, and then click OK.
Obtaining information about common issues by using the chatbot
Deployment Manager provides a chatbot that you can use to obtain information about common issues, such as connectivity between systems, configuring Jenkins, and branch merging. After you enter your search text, the chatbot provides you with relevant answers and links to more information.
- If the chatbot is disabled, enable it. For more information, see Enabling and disabling the chatbot.
- In the bottom right corner of the Deployment Manager portal, click the chatbot icon.
- Do one of the following actions:
- Click the appropriate link from the list of issues that the chatbot displays.
- Enter text for which you want to receive more information, and then click Enter.
- Optional: To clear the chatbot history, in the chatbot window, click the More icon, and then click Clear chat history.
Enabling and disabling the chatbot
Use the chatbot to obtain more information about common Deployment Manager issues, such as branch merging and pipeline configuration. You can disable and enable the chatbot. By default, the chatbot is enabled.
- In the navigation pane of Deployment Manager, click Settings > General settings.
- Do one of the following actions:
- To enable the chatbot, select the Enable self-service Deployment Manager chatbot check box.
- To disable the chatbot, clear the check box.
- Click Save.
- At the top of the General Settings page, click the back arrow icon.
- Click the refresh icon to refresh Deployment Manager and apply your changes.
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 the required privileges. For more information, see Configuring settings to automatically deploy schema changes.
Your user role determines if you can manage schema changes. For more information about user roles, see Roles and users.
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.
- On the candidate system, in Pega Platform, set the AutoDBSchemaChanges dynamic system setting to true to enable schema changes at the system level.
- In Dev Studio, search for AutoDBSchemaChanges.
- In the search results dialog box, click AutoDBSchemaChanges.
- On the Settings tab, in the Value field, enter true.
- Click .
- 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.
Schema changes are also attached to the deployment report for the pipeline.
Completing or rejecting a manual step in a deployment
If a manual step is configured on a stage, the deployment pauses when it reaches the step, and you can either complete it or reject it. For example, if a user was assigned a task and completed it, you can complete the task to continue the deployment. 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.
Your user role determines if you can complete or reject a manual step. For more information about user roles, see Roles and users.
To complete or reject a manual step within the deployment, do the following steps:
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Click one of the following links:
- Complete: Resolve the task so that the deployment continues through the pipeline.
- Reject: Reject the task so that the deployment does not proceed.
To complete or reject a manual step from within an email, click either Accept or Reject.
Managing aged updates
An aged update is a rule or data instance in an application package that is older than an instance that is on a system to which you want to deploy the application package. By being able to import aged updates, skip the import, or manually deploy your application changes, you now have more flexibility in determining the rules that you want in your application and how you want to deploy them.
For example, you can update a dynamic system setting on a quality assurance system, which has an application package that contains the older instance of the dynamic system setting. Before Deployment Manager deploys the package, the system detects that the version of the dynamic system setting on the system is newer than the version in the package and creates a manual step in the pipeline.
Your user role determines if you can manage aged updates. For more information about user roles, see Roles and users.
To import aged updates:
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Optional: Click View aged updates to view a list of the rules and data instances, which are in the application package, that are older than the instances that are on the system.
- Click the More icon and select one of the following options:
- Click Overwrite aged updates to import the older rule and data instances that are in the application package into the system, which overwrites the newer versions that are on the system.
- Click Skip aged updates to skip the import.
- Click Deploy manually and resume to manually deploy the package from the Import wizard on the system. Deployment Manager does not run the Deploy step on the stage.
Pausing and resuming deployment
When you pause a deployment, the pipeline completes the task that it is running, and stops the deployment at the next step.
Your user role determines if you can pause a deployment. For more information about user roles, see Roles and users.
To pause a deployment:
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Click the pipeline.
- Click .
- To resume the deployment, click Pause again.
Stopping a deployment
Your user role determines if you can stop a deployment. For more information about user roles, see Roles and users.
To stop a deployment:
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Click the Moreicon, and then click Abort.
Managing a deployment that has errors
If a deployment has errors, the pipeline stops processing on it. You can perform actions on it, such as rolling back the deployment or skipping the step on which the error occurred.
Your user role determines if you can rollback and stop a deployment. For more information about user roles, see Roles and users.
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Click the More icon, and then click one of the following options:
- Resume from current task – Resume running the pipeline from the task.
- Skip current task and continue – Skip the step and continue running the pipeline.
- Rollback – Roll back to an earlier deployment.
- Abort – Stop running the pipeline.
Viewing merge requests
You can view the status of the merge requests for a pipeline. For example, you can see whether a branch was merged in a deployment and when it was merged.
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- In the Development stage, click X Merges in queue to view all the branches that are in the queue or for which merge is in progress.
- In the Merge requests ready for deployment dialog box, click View all merge requests to view all the branches that are merged into the pipeline.
Viewing deployment reports
Deployment reports provide information about a specific deployment. You can view information such as the number of tasks that you configured on a deployment that have been completed and when each task started and ended. Any schema changes are also attached to the deployment report.
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Perform one of the following actions:
- To view the report for the current deployment, click the More icon, and then click View report.
- To view the report for a previous deployment, expand the Deployment History pane and click Reports for the appropriate deployment.
Viewing reports for all deployments
Reports provide a variety of information about all the deployments in your pipeline. You can view the following key performance indicators (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 production
- Start frequency – Frequency at which new deployments are triggered
- Failure rate – Average number of failures per deployment
- Merges per day – Average number of branches that are successfully merged per day
To view reports, do the following tasks:
- Do one of the following actions:
- If the pipeline open, click Actions >View report.
- If a pipeline is not open, in the navigation pane of Deployment Manager, click Reports. Next, in the Pipeline field, press the Down arrow key and select the name of the pipeline for which to view the report.
- Optional: From the list that appears in the top right of the Reports page, select whether you want to view reports for all deployments, the last 20 deployments, or the last 50 deployments.
Archiving and activating a pipeline
If your role has the appropriate permissions, you can archive inactive pipelines so that they are not displayed on the Deployment Manager landing page. For more information about roles, see Roles and users.
To archive and activate pipelines, do the following steps:
- To archive a pipeline, perform the following steps:
- In the navigation pane of Deployment Manager, click .
- Click the More icon, and then click Archive for the pipeline that you want to archive.
- In the Archive pipeline dialog box, click .
- To enable an archived pipeline in Deployment Manager, perform the following steps:
- In the navigation pane of Deployment Manager, click Pipelines > Archived Pipelines.
- Click Activate for the pipeline that you want to activate.
- In the Activate pipeline dialog box, click .
Disabling and enabling a pipeline
If your role has the appropriate permissions, you can disable a pipeline on which errors continuously cause a deployment to fail. Disabling a pipeline prevents branch merging, but you can still view, edit, and stop deployments on a disabled pipeline. For more information about roles, see Roles and users.
To disable and enable a pipeline, perform the following steps:
- In the navigation pane of Deployment Manager, click .
- To disable a pipeline, perform the following steps:
- Click the More icon, and then click Disable for the pipeline that you want to disable.
- In the Disable pipeline dialog box, click Submit.
- To enable a disabled pipeline, click the More icon, and then click Enable.
Deleting a pipeline
When you delete a pipeline, its associated application packages are not removed from the repositories that the pipeline is configured to use.
Your user role must have permission to delete a pipeline. For more information, see Roles and users.
- In the navigation pane of Deployment Manager, click .
- Click the More icon, and then click Delete for the pipeline that you want to delete.
- In the Delete pipeline dialog box, click Submit.
- Click .
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 a separate product rule to manage a test application, the name of the product rule is the same as that of the product rule with _Tests appended to it.
If you are using Deployment Manager on Pega Cloud Services, application packages that you have deployed to cloud repositories are stored on Pega Cloud Services. To manage your cloud storage space, you can download and permanently delete the packages.
- If the pipeline is not open, in the navigation pane of Deployment Manager, click , and then click the name of the pipeline.
- Click Actions > Browse artifacts.
If you are using Sonatype Nexus Repository Manager 3 repositories, the Published On and Size columns are not displayed.
- On the Artifacts page, click either Development Repository or Production Repository.
- To download a package, click the package, and then save it to the appropriate location.
- To delete a package, select the check boxes for the packages that you want to delete and click Delete.