Deployment Manager application pipelines

In this video, you will learn about the Deployment Manager environments. You will also understand the significance of different application pipelines in Deployment Manager that are relevant to Customer Decision Hub implementations.

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.

Deployment Manager environments

The orchestrator has the Deployment Manager installed in it and it orchestrates all the tasks as defined in the different application pipeline models. Orchestrator exposes the pipeline modeling experience for users to design their deployment pipelines. It resides on a dedicated Pega server which is configured to interact with each of the candidate systems.

Each Pega environment managed by Deployment Manager is known as a candidate system. Candidate systems execute most deployment tasks at the direction of the orchestrator. The candidate environments use a default operator and authentication profiles to establish communication with the orchestrator system. 

Among the candidate environments, the development environment has special responsibilities, as merges are performed on this environment. Application packages are generated in this environment during deployments.

The development environment is referred to as the system of record (SoR) to highlight these responsibilities.

Deployment Manager stores application artifacts that are created throughout the life cycle of a deployment within a repository. To use Deployment Manager, you need a supported artifact repository.

Candidate systems use repositories to move application artifacts when they are promoted between environments. The deployment process automatically versions application artifacts.

In a typical decision management project, a development team, and a business operations teamwork on various application artifacts.

Because various teams work on several artifacts in different environments, you need a consistent methodology and a process to ensure that the artifacts that are created are synchronized and consistent across all four candidate environments. To keep these artifacts up to date across all the environments, you use application pipelines.

You will learn about three application pipelines that leverage DevOps best practices for Customer Decision Hub implementation to deploy revisions and test how changes made to decision strategies might reflect in real-life scenarios.

Enterprise change pipeline

The development team works on core application changes as part of enterprise release cycles to improve the capability of the application and to meet more business requirements. The changes that are made as part of the enterprise release cycles are tested and deployed through an enterprise change pipeline. Examples of a typical core application change include creating a new customer property, integrating an additional channel, and creating a new service to gather additional customer data, and so on.

The enterprise change pipeline is used to migrate core application changes released by the development team.

All these changes are packaged and pushed from the development environment to staging, BOE, and then to the production system by using the enterprise change pipeline.

Updates to application functionality are handled through typical developer practices such as branching and ruleset lock-and-roll. For the Customer Decision Hub Implementation application, updates are typically maintained in the Rules ruleset and any other client-specific rulesets. Nothing in the Artifacts ruleset should flow through this pipeline.

Business change pipeline

Business change pipelines support business changes to your Pega Customer Decision Hub application. This pipeline offers Customer Decision Hub business users the means to deploy changes that are implemented to their applications outside the enterprise release cycles.

The business content team and enterprise capabilities team make business changes in the BOE.

You can make two types of business changes to your Customer Decision Hub application from the BOE. The first type is a change request that is initiated in the 1:1 Operations Manager application. For example, the change might be creating an action, creating a web treatment, or updating an action-level eligibility condition. These requests are usually high-volume business changes that the business content team manages. The other type includes changes that are not managed by 1:1 Operations Manager but completed using revision management capabilities in the Customer Decision Hub portal on the BOE. For example, the change might be modifying updating a decision strategy that implements eligibility conditions, using a new decision table, or a scorecard to implement specific business requirements, and so on. These changes are low-volume capability changes that the enterprise capabilities team manages. You can deploy both these changes as part of a single revision.

When a business change is completed, you can deploy the change from the BOE to all other environments. After the deployment from the BOE is initiated, the artifacts that are related to the new revision are merged into the branch in the development environment. After the branch is merged to the enterprise application, a new version of the enterprise application is created. This application is then packaged and moved to higher environments - staging, BOE, and production.

Data migration pipeline

Typically, after implementing the business changes, you need to simulate the result of the changes to understand if the business outcomes are as expected. Simulation tests provide you with significant insight into how your changes to decision logic affect the results that your strategies produce. However, if tests are based on sample data, the results do not always reflect the effect that your changes have in real-life scenarios. To ensure that simulations are reliable enough to help you make important business decisions, you can migrate a sample of your production data to BOE.

The data migration pipeline provides you with the means to test how the changes that you make to decision strategies affect their results, without running these strategies in a live production environment.

By using a data migration pipeline, you can export a sampled dataset, which includes inbound and outbound interaction history and adaptive models, from the production environment, and then import that data into the BOE. As a result, the simulations are based on the migrated production data and enable you to assess how your changes are reflected in real-life scenarios.

For example, you can sample a selection of 20% of real customer interactions, and then migrate the data to the BOE to test how the changes to existing strategies may affect the business outcomes.

You can also schedule a data migration pipeline to run during a specified period by creating and running a job scheduler.

To summarize, successfully setting up Deployment Manager to conduct proper change management and provide sampled production data for simulations enables businesses to seamlessly deploy revisions and test how decision strategy changes affect real-life scenarios.