Creating an enterprise change pipeline for initial deployment

This demo shows you how to create an enterprise change pipeline to deploy the application, which the project team developed in the Development environment, for the first time.

U+ Bank, a retail bank, has recently installed the Pega Deployment Manager application and wants to configure the deployment manager to create an enterprise change pipeline that facilitates initial development changes that the developers made in the implementation application.

A typical decision management project includes five environments. A Development environment to develop enterprise features, the system of record, a UAT/Staging environment to test the changes and analyze technical impact, a Business Operations Environment (BOE) to make business changes and run simulations, a production environment to serve customers with the most recent artifacts, and an orchestrator to manage and automate deploying artifacts from one environment to another.

In this case, you begin by setting up the orchestrator environment, and then configuring the candidate systems--Development, Staging, BOE, and Production--to communicate with the orchestrator. Finally, in the orchestrator, you define an enterprise change pipeline to facilitate the initial deployment.

This is the orchestrator. The orchestrator has the Deployment Manager and PegaDevopsFoundation application installed. To configure an environment as the orchestrator, you set the Orchestrator URL to the URL of that environment.

In a typical scenario, you update the PegaDevOpsShared dynamic system setting in the candidate systems to point to the orchestrator system URL. On the candidate systems, only the PegaDevopsFoundation application is installed along with Pega Customer Decision Hub.

Now, the candidate systems are linked to the orchestrator system.

Deploying initial development changes involves preparing the deployment and the actual deployment through an enterprise change pipeline.

As a first step, you need to have a product rule to use for packaging the artifacts in the development environment and a system architect typically creates this rule.

This product rule includes a list of applications and components. In this example, the system architect has included applications and components built on top of Pega Customer Decision Hub, rulesets that were added or modified as part of the core application changes, other rules such as relevant records and indexes for the containers, and the individual instances to include rules, such as the access groups and work groups.

Next, you must create an enterprise change pipeline in the Deployment Manager portal in the orchestrator. With the enterprise change pipeline, you deploy the core application changes, establish communication between environments, and then define the sequence of tasks to perform in each environment.

Deployment Manager comes with pipeline templates that help you structure pipelines based on their purpose.

For this requirement, use the Deployment Pipeline template. Start by defining the Application packaging environment, which is typically your development environment that acts as the system of record (SOR) and contains the product rule that defines how the application is packaged. In this case, enter the development environment URL.

Then, select an Authentication profile to communicate with the candidate environments, and connect to the application packaging environment (development) to build the deployment package. An authentication profile is created when you install Deployment Manager. The orchestrator uses this authentication profile to communicate with candidate systems to run tasks in the pipeline. You must have this authentication profile in all the candidate systems with the same operator ID.

As your next step, select the name and version of the overlay application, which is the application where the business changes will reside.

Then, select the access group for which you want to run the pipeline tasks. Ensure that this access group is in all environments.

Now, enter the name and version of the product rule to use for packaging the artifacts to deploy to the other candidate systems.

Enter a unique name for the pipeline, in this case, Initial Deployment.

Next, configure the candidate environment details.

Notice that the development environment system URL is already populated based on the information that you provided earlier.

A generic enterprise change pipeline has Development, Quality Assurance, Staging, and Production as the candidate environments. As a typical decision management project includes Development, Staging, Business Operations, and Production, rename the candidate systems to reflect the required environments.

Enter the URLs of the other candidate systems, and then select the authentication profile for each system.

Now, specify the development and production repositories where you want to store the packaged rules. The pipeline uses the development repository to generate artifacts and version for an application. The pipeline uses the production repository to store the production-ready artifacts.

The environments in the pipeline import the application package directly from these repositories. In this case, use the same repository.

A pipeline model is created. The pipeline model is a case type that defines various predefined tasks that are necessary to accomplish a successful initial deployment.

From here, you can adjust your stages and tasks to replicate the quality standard of the release process that your organization defines.

In the Check application compliance step of the Development environment, clear the options in input parameters to include test rulesets and branches as some out-of-the-box test rulesets are in the application, and the overlay application branch should also be migrated.

In the Check guardrail compliance step of the Staging environment, enter a guardrail threshold score that is less than your application score. For high performance, Pega recommends a high guardrail score for applications. In this case, as the application guardrail score is 84, a lower score of 80 is set as the threshold.

In the Validate test coverage step, enter the percentage of test coverage for the application, data types, and case types. This case has no test coverage. Consequently, the value is set to zero.

In the Check guardrail compliance step of the Business Operations environment, set the guardrail score as you did in the Staging stage.

These adjustments to the stages and steps ensure that the default settings do not affect the application package creation and deployment.

Run diagnostics to check whether the orchestrator can communicate with all candidate systems and whether the pipeline details are defined correctly. If the check is successful, you can use the pipeline for the initial deployment.

The Release manager initiates the deployment process by using the enterprise change pipeline that is created in the Deployment Manager in the orchestrator environment.

Deployment Manager orchestrates the process, and then the candidate environments run the tasks in the pipeline model. The application is packaged and sent to the repository to make them available to other environments that are defined in the pipeline.

You can see the progress of the deployment and each completed task. Monitoring the process in Deployment Manager helps in debugging.

Notice that the process indicates an action that the user needs to complete.

When the deployment is successful, you can view the report in the Deployment history section to check the process details and logs.

You have reached the end of this demo. What did it show you?

• How to create an enterprise change pipeline and establish communication between environments using the pipeline.
• How to facilitate an initial deployment using an enterprise change pipeline.
• How the core application changes are deployed from the development environment to the higher environments.