Modular deployment strategies

Dedicating a ruleset to a single case type helps to promote reuse. Other reasons to dedicate a ruleset to a single case type include:

Achieving continuous integration (CI) branch-based development.
Encouraging case-oriented user stories using Agile Studio’s scrum methodology to manage project software releases.
Managing branches that contain rules that originate from different rulesets. When this occurs, a branch ruleset is generated, and the generated ruleset prepends the original ruleset's name to the branch name.
Accommodating multiple user stories in a branch.
Simplifying the ability to populate the Agile Workbench Work item to associate field when checking a rule into a branch.

rule_checkin — This diagram shows how to map the Agile Workbench Work item while a rule is being checked into a branch.

When you create a project within Agile Studio, a backlog work item is also created. When developing an application built on a foundation application, the Agile Studio backlog can prepopulate with a user story for each foundation application case type. Case types appropriate for the Minimal Loveable Product (MLP) release can then be selected from that backlog.

Pega’s Deployment Manager provides a way to manage CI/CD pipelines, including support for branch-based development. It is possible to automatically trigger a Dev-to-QA deployment when a single branch successfully merges into the primary application. The rules checked into that branch must only belong to the primary application for this to occur.

When a case type class is created within a case type-specific ruleset, rules generated by the Case Designer in Dev Studio are added to that ruleset despite the Case Designer supporting the development of multiple case types within the same application.

Branch-based development review

Application branches are managed in the App Explorer of Dev Studio’.

BookEvent-branch — This diagram shows how to add a branch to an existing application using Dev Studio.

While it is not necessary to dedicate a branch to a single case type, as shown in the following image, doing so simplifies the branch review process.

BookEvent-branch-list — This diagram shows the newly added branch in the Branch explorer in the Dev Studio.

When a case-related rule in a case-specific ruleset is saved to a branch, a case-specific branch ruleset generates if one does not already exist. Changes made within the Case Designer that affect that rule occur within the branch ruleset’s version of that rule. When a branch ruleset is created, it is placed at the top of the application's ruleset stack.

BookEvent-branch-appstack — This diagram shows the branch ruleset placed automatically at the top of the application's ruleset stack when a new branch is added.

The merge of a single branch is initiated from the Application Explorer’s Branches tab by right-clicking on the branch name to display a menu.

BookEvent-branch-merge — This diagram shows how the branch is merged into main ruleset from the Branch explorer in Dev Studio.

At the end of the merge process, the branch will be empty when the Keep all source rules and rulesets after merge option is not selected. The branch can then be used for the next sets of tasks, issues, or bugs defined in Agile Studio.

Deployment Manager branch-based development

Consider a scenario in which the Deployment Manager application, running on a separate orchestration server, is configured to automatically initiate a delivery when a single-branch merge completes an application successfully. Also, suppose the development environment application, built on the same PegaDevOpsFoundation application, configures the RMURL (Release Manager URL) Dynamic System Setting (D-S-S) to point to the orchestration server’s PRRestService. When initiating a single-branch merge, the development environment sends a request to the Deployment Manager application. The Deployment Manager application orchestrates the packaging of the application within the development environment, the publishing of that package to a mutual Dev/QA repository, and the import of that package into the QA environment.

Application packaging

The initial Application Packaging wizard screen asks which built-on applications and the application being packaged should be included in the generated product rule. Note that components are also mentioned, a component being a Rule-Application where pyMode = Component.

Multiple applications referencing the same ruleset is highly discouraged. After saving an application rule to a new name, warnings appear in both applications — one warning for each dual-referenced ruleset.

The deployment strategy is different when the production application being deployed is dependent on other multiple built-on component applications.

If the product file contains Database schema changes as a part of the deployment and if your Organization policies do not support applying the Database schema changes automatically, you need to generate the SQL for schema changes and get it executed by the DBA manually before continuing with the rules deployment.

Application_version — This figure shows applications A1 and A2 being versioned going to the right. Application A3 is built on A1 and A2. Applications A1 and A2 are not productions application. Nonetheless, applications A1 and A2 can be deployed to other development team environments such as the environment where application A3 is developed. It is applications A3’s responsibility to observe the version change made by application’s A1 and A2. At some point application A3 must decide to change its versions as well to reflect the version changes taking place beneath it.

Consider the example of the FSG Booking application. The FSGEmail application is packaged first, followed by the Hotel application, followed by the Booking application.

While it is possible to define a product rule that packages a component only, there is no need to do so. The component can be packaged using the component rule itself, as shown in the following image.

Component_example — This diagram shows how the component can be packaged using the component rule as a part of the deployment.

Deployment Manager supports pipelines for rule application instances where pyMode = Application and pyMode = Component. When an application is packaged and contains one or more components, those components should also be packaged.

product_rule — This figure demonstrates that a component can be packaged in the Product rule along with an application that uses the component. The component is named EmailEditor. The application is named FSGEmail.

The Open-Closed principle applied to packaging and deployment

The goal of the Open-Closed principle is to eliminate ripple effects. A ripple effect occurs when an object makes changes to its interface as opposed to defining a new interface and deprecating the existing interface. The primary interface for applications on which other applications are built, such as FSGEmail and Hotel, is the data required to construct the new interface using data propagation. If the EmailEditor component mandates a new property, the FSGEmail application needs to change its interface to applications that are built on top of it, such as the Hotel application. The Hotel application then needs to change its built-on interface to allow the Booking application to supply the value for the new mandated property.

By deploying applications separately and in increasing dependency order, the EmailEditor component change eventually becomes available to the Booking application without breaking that application or the applications below it.

Note: It is not a best practice to update all three applications (FSGEmail, Hotel, and Booking) using a branch associated with the Booking application.

This Topic is available in the following Module:

Release pipeline introduction v3

If you are having problems with your training, please review the Pega Academy Support FAQs.

Did you find this content helpful?

Yes

Want to help us improve this content?

Suggest an edit

Get Started with Community