Establishing a prescriptive Route to Live
Establishing a prescriptive Route to Live
| Pega Cloud Prescriptive Route to Live | |
|---|---|
| New URL | https://docs.pega.com/bundle/pega-cloud/page/pega-cloud/pc/learning-about/establishing-prescriptive-route-to-live.html |
| This article has been moved over to our Pega Community here in order to align with our larger content strategy. Please update any bookmarks or links that you may have to this location. | |
Establishing a prescriptive Route to Live: Moving your application from ideation to continuous delivery in Pega Cloud
The goal of this content is to either introduce or reinforce the requirement for establishing prescriptive Routes to Live (RTL) for your Pega applications deployed in Pega Cloud© Services that are efficient, easily upgradable and that allow for continuous improvement. This document focuses on how clients can create RTLs from an environmental view, which thereby helps you ensure that you use your Pega Cloud assets effectively, which lowers costs and improves delivery results. It answers the most common questions and concerns our clients raise around how they align their software development lifecycle (SDLC) with our recommended best practices for development; it also defines the existing demarcation points with which you can separate several RTLs.
An accompanying document, which developers and implementers can use, The prescriptive application release life cycle, focuses on how to leverage the rich capabilities of Pega Platform™ and Deployment manager. You and your team should review the second article before, during, or after using this RTL document.
Introduction to Routes to Live
Pega clients require solutions which are continuously evolving to meet the demands of the world around them. In practice, this means delivering rapidly, iterating more frequently, and verifying that the choices you make to establish your solution lifecycle meet these demands, and deliver high-quality results.
Pega recommends organizing delivery around the concept of RTLs. RTLs include a packaged set of services that align to the functions/stages used to deploy new applications and continuously improve existing ones. The most common stages of an application lifecycle are listed below. Note: Not all elements of the life cycle are always used:
- Development Stage
- Development – The technical configuration of Pega applications. Using Dev, App, or Prediction Studio to build integrations, create case workflows, control adaptive models, or to continuously improve existing solutions.
- Quality Assurance – The testing stage associated with a Pega Application, validating and testing scenarios, integrations, and unit testing.
- Integration Testing – End-to-end testing of a Pega solution which can be composed of many sub-systems. The main objective of integration testing is to ensure that all dependencies are functioning properly.
- Staging Stage
- User Acceptance Testing – One of the final stages, ensuring that actual users of the software can handle their day to day tasks, under real-world scenarios according to a defined specification.
- Training – A stage where users of the systems can be made of aware of changes to the solution that impact usability before they impact productivity.
- Production Stage
- Performance Testing – A stage that validates that the end-to-end solution can support the full workload, without undue delays.
- Productive (Production) – The stage where a solution is live and servicing production users and workloads.
- Business Operations (Specific to Pega Customer Decision Hub) – Used to perform functional simulation testing against the most recent engagements, their activity history, and their analytical model.
Service Definition
These functional elements of the service life cycle are performed within the following environment types as defined by Pega Cloud Services.
- Standard Sandbox – A general-purpose sandbox that supports development, functional/unit testing, user acceptance testing and pre-production staging.
- Large Sandbox – A general-purpose sandbox supports development, functional/unit testing, training, user acceptance testing and pre-production staging.
- Production Mirror Environment – The Production Mirror Sandbox is scaled to support application performance testing up to the volume of the Production Environment service.
- Production Environment – The Pega Cloud Service Production Environment is a scaled production deployment of licensed Pega Platform and applications.
- Business Operations Environment – The Business Operations Environment supports functional simulation testing of decisioning applications in batches of a contractual defined window.
Deployment Best Practices
RTL foundations
The following guidance and illustrations visually depict the most common and recommended RTLs for the core Pega CLoud Services product offerings.
Definitions
To ensure you have a good foundation, here are the environment types and use case definitions used in the illustrations below:
- Dev = Development
- QA = Quality Assurance
- UAT = User Acceptance Testing
- Trn = Training
- PM = Production Mirror (performance testing)
- Prod = Production
- DM = Deployment Manager
Intelligent Automation or Customer Service RTL
- A typical Intelligent Automation or Customer Service RTL will look like one of these two illustrations below. Notice that:
- Functional roles like UAT and Training can share an environment.
- These resources can be scaled to support additional demands.
- Deployment orchestration is managed exclusively by Deployment Manager (DM).
- The primary difference between these two RTLs is that the latter includes a PM environment, which you use for scaled performance testing.
1:1 Customer Engagement or Customer Decisioning RTL
- A typical 1:1 Customer Engagement or Customer Decisioning RTL will look like one of these two illustrations below. While this RTL is very similar to Intelligent Automation and CRM RTLs mentioned above, these RTLs include a specific environment type, the BOE, which is only used by customer decision hub solutions and is leveraged for certain personas to commit changes.
Leveraging RTLs for Your Applications - Best Practices to Successful Releases
Use the following guidelines to successfully create an RTL to deliver the latest optimizations of your application to your application in production:
- A single Intelligent Automation or Customer Service RTL can support multiple applications and versions. To understand how to create an application release life cycle that supports this, please review The Prescriptive Application Release Life Cycle.
- A production environment within your RTL must always have an accompanying staging environment. This means that for a given RTL, as illustrated below, there must always exist a “staging stage” environment as shown in green.
- Application(s) that are deployed in your staging environment must match the application(s) that are deployed in production. Pega Cloud Services infrastructure and software updates rely on the staging environment to be representative of production to ensure that the Pega Cloud update validation process works correctly. Deviations from this invalidate Pega Cloud validation testing. For more information about the process, see Pega Cloud Services update process for Pega Infinity release 8.4.2 and later.
- When you leverage Pega solutions for multiple separate business applications, such as Customer Service, Intelligent Automation, and 1:1 Customer Engagement, Pega strongly recommends having a distinct RTL for each application where you apply Pega technology.
- All applications deployed within the same RTL share the same Pega update and change management process.
- All applications deployed within the same RTL will have the same Pega maintenance windows and patch policy.
- Reusability of application components is strongly recommended by Pega. As a rule of thumb, when applications share common components, they should exist within the same RTL. This is because including shared assets and dependencies can be difficult if applications do not share the same RTL.
- A single Intelligent Automation or Customer Service application must be developed within a single development environment and cannot be spread across multiple development environments. Pega Cloud Services supports accommodating large developer communities within a single development environment.
- A 1:1 Customer Engagement application can have two “entry points” for development. A development environment for technical changes that involves the development system of record (SOR), and a business operations environment for business operator changes. For details, see the illustration for 1:1 Customer Engagement application development lifecycle
- All changes within a 1:1 Customer Engagement application must be merged within a common development environment. The process described above leveraging 1:1 operations manager is depicted below:
- Pega Deployment Manager is the only recommended approach for deploying and managing the development life cycle of solutions deployed on Pega Cloud Services.
- A single RTL will store all data that is created from or stored when executing the application, within the region(s) where it is deployed.
- 1:1 Customer Engagement RTLs can only contain one “application.”
- 1:1 Customer Engagement use cases that span lines of business but operate against the same customer base should be done within a single RTL. This ensures that the centralized “brain” is able to view all data elements of the customer engagement.
- Decisioning use cases where the lines of business do not overlap and have very different customers should operate within different RTLs. For example, a business to business application versus a business to consumer application.
Frequently Asked Questions
When does Pega recommend that all Intelligent Automation or CRM applications, reside within a single RTL?
Based on the best practices illustrated above, if you answer yes to the statements below, your applications are recommended to follow this design pattern:
- Data doesn’t need to reside in multiple different regions because of data sovereignty or other regulatory or compliance requirements.
- The lines of business that these applications service can operate under a single update timeline and policy.
- Decisioning applications that may span multiple lines of business but interact with the same customer base.
- The lines of business that these applications service can operate under a single patch and maintenance timeline and policy.
- Those applications share common application layers and frameworks.
- These applications do not have a similar mission criticality profile; those applications living in a single RTL should not all be 24x7, high volume, mission critical workloads.
When does Pega recommend that Intelligent Automation or Customer Service applications, be deployed in separate RTLs?
We can provide guidance based on our best practices defined above, if you answer yes to the statements below, your applications are recommended to follow this design pattern:
- Applications servicing a global user base, impacted by data sovereignty or other regulatory and compliance requirements that require that data cannot be moved from the data subjects' region into a single region of operation.
- The lines of business that these applications service cannot adhere to a single update timeline and policy because it would create unmanageable prioritization and coordination amongst disparate teams.
- The lines of business that these applications service cannot operate under a single patch and maintenance timeline and policy, because it would create unmanageable prioritization and coordination amongst disparate teams.
- These applications have a similar mission criticality profile: these workloads are similarly operated, such as when usage is 24x7, there is high volume of processing, and it is a mission critical application.
When does Pega recommend that 1:1 Customer Engagement applications be deployed in separate RTLs?
1:1 CE solutions that target a materially different customer base, for example B2B vs B2C. Or more specifically when the benefit of operating off a single data set and evaluating across different lines of business for the same customer base provides no benefit.
When does Pega recommend 1:1 Customer Engagement applications be deployed in a common route to live?
All applications target a similar customer base. Critical to this thought process is, if there is benefit to your strategies to have a centralized brain evaluating all interactions, you should be deploying a single RTL.
Does Pega recommend including 1:1 Customer Engagement and Customer Service or Intelligent automation workloads in the same RTL?
No, Pega recommends that these exist in isolated RTLs.
When Pega performs updates, will all applications within a single RTL be updated in the same workflow?
Yes
When Pega performs maintenance, such as patches or infrastructure updates, will all applications within a single RTL receive these changes in the same workflow?
Yes
Can a single community of developers, working on the same application span multiple development sandboxes?
No. We do not recommend or support application development spanning multiple environments, due to synchronization requirements.
Do I have to ensure that my “staging” sandbox contains an identical set of applications to those running in production?
Yes. Our update process and testing strategies rely on a staging environment that matches production.
Can a single route to live support multiple intelligent automation applications and versions?
Yes! And in fact, it is common place. Our prescriptive RTL content provides details on the ways to achieve this with native Pega capabilities.
How many applications can I create in a single 1:1 customer engagement RTL?
One.
I do performance testing on every major release, what do I need to accomplish this?
Pega provides an RTL with a production mirror environment. Production mirror environments are scaled to support production level volume testing.
Supporting Content and Best Practices
- The Prescriptive Application Release Life Cycle
- Access your Pega Cloud Services
- Using Deployment Manager for Model Driven DevOps
- Quick-start guide for Deployment Manager on Pega Cloud Services
- Download Deployment Manager from the Pega Marketplace
- Configuring an application structure managed using Deployment Manager