Configuring a business change pipeline

Video
 

Transcript

This demo shows you how to configure a business change pipeline to deploy changes that are implemented by the business content team and enterprise capabilities team in the Business Operations environment.

U+ Bank, a retail bank, has recently installed the Pega Deployment Manager application and wants to configure Deployment Manager to set up a business change pipeline so that the business team can efficiently implement business changes outside of the enterprise release cycle for faster market response.

A typical decision management project has five environments involved. An orchestrator to manage and automate the deployment process of artifacts to the candidate environments. A development (System of Record) environment to develop enterprise capabilities. A staging environment to test the changes and analyze their technical impact. A Business Operations Environment (BOE) to make business changes. A production system to serve real customers with the latest and greatest artifacts.

In this case, you first set up the orchestrator environment, then configure the candidate systems (Development, Staging, BOE, and Production) to communicate with the orchestrator. Finally, in the orchestrator, you define a business change pipeline to define the deployment process of a business change.

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

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

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

Next, you need to configure a business change pipeline in the Deployment Manager portal in the orchestrator. With the business change pipeline, you can deploy the implemented changes by establishing communication between environments and defining 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 Business Change Pipeline template. Start by defining the Application packaging environment. This 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 automatically 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 standard release application, which is the application where business changes reside.

Then, select the access group for which you want to run the pipeline tasks. Ensure that this access group is present 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, Business Change.

Then, select the New ruleset version option and provide a password. This action creates and locks a new ruleset version that contains business changes after a successful merge.

Next, configure the candidate environment details.

Notice that the development environment system URL is already populated based on the information that you provided earlier. Enter the URLs of all the other candidate systems, and then select the authentication profile for each system.

Now, specify the development and production repositories where in which you want to store the packaged rules. Define at least one repository that each candidate system can access.
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. Having a separate production repository is optional.

The environments in the pipeline directly import the application package 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 business change deployment.

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

In the Create application version task, enter the enterprise application name for the input parameter. After a business change branch is merged, a new version of the enterprise application is created which is then deployed to other environments. Create the pipeline.

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

In the development environment, navigate to the overlay application to view the current state of the application stack and versions.

OLSTDRCH is the overlay application, which is built on CDH 01.01.01 (the enterprise application) and Ops Manager Extension. Note that the patch version should not be provided in the application ruleset version and should only include the minor version 01-01.
The OLSTDRCDHRM is a branch of the OLSTDRCDH ruleset. The current version is 01-01-01. This branch is where you create business changes.

When you deploy a revision, a new version of the enterprise application is created with an incremented application version. This new enterprise application version points to the merged overlay application version and a new ruleset version is available in the overlay application with the new set of rules added. Currently, there is 1 rule in the OLSTDRCDH ruleset.

Now, in the BOE, open the overlay application ruleset to view the rules within the branch. Currently, no rules need to be deployed because a new revision is not created yet.

Let us consider a regular business change use case where business requested the addition of a new action: Cashback 15 card. This is a typical business change, and the business content team starts working on this request in the BOE system. A business user first creates a change request in Pega 1:1 Operations Manager to initiate adding a new action. Then, a team leader prioritizes the change request and assigns the request to an NBA Specialist for build. Next, the NBA Specialist completes the action build tasks. The Team leader then confirms the changes and sets the change request ready for deployment. The business change is finally complete.

Review the current state of the overlay application in the BOE system before proceeding with the deployment. Open the overlay application ruleset to view the rules within the branch. All changes that were made to the rules are stored in the branch ruleset. Note that a new action with the name Cashback15card was added.

The Revision manager now initiates the deployment process by using the business change pipeline that is configured in the Deployment Manager in the orchestrator environment.

The rules in the branch are packaged and sent to the repository to make them available to other environments that are defined in the pipeline.

Deployment Manager starts orchestrating the process and the candidate environments run the tasks that are defined in the pipeline model. You can see the progress of the deployment and each completed task. The default way to monitor the process is in the Revision Management portal. However, monitoring the process in Deployment Manager also helps in debugging.

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

After the new application version is migrated to all environments, within the BOE environment, select a subset of users to test the modifications in the production environment and roll out the changes to all users when the test results are acceptable.

In this case, select all the users.

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

After activating the change for all users and completing the revision, the change is available to all users.

At this point, in the development environment, navigate to the overlay application to view the current state of the application stack and versions. Note that a new enterprise application was created with version 01.01.02 and the OLSTDRCDH application now inherits from this application. This new enterprise application has the merged ruleset version (OLSTDRCDH:01-01-02).

Open the ruleset to view the new ruleset version and the rules available. According to the initial pipeline configuration, the branch was merged as a new ruleset and is locked. Open the latest ruleset to view the new action that was added. Notice that this ruleset also contains all the rules that were added in the BOE system branching ruleset and is now part of the development system and the other candidate systems after deployment.

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

• How to configure a business change pipeline and establish communication between environments using the pipeline.
• How to create and deploy a revision through a business change pipeline.
• How a new version of an enterprise application and an application overlay ruleset is created for every revision.

The process of creating a fast release business change pipeline is the same as the standard release business change pipeline. However, when configuring the fast release pipeline, use:

1. The name and version of the overlay fast release application, which is the application where emergency/unplanned business changes reside.
2. The access group for which you want to run the fast release pipeline tasks. Ensure that this access group is present in all environments.
3. The name and version of the product rule to use for packaging the fast release artifacts to deploy to the other candidate systems.
   

Both standard release and fast release changes are deployed using a single overlay ruleset.

Fast release business changes can be deployed without disrupting the standard release cycle.