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.
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’.
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.
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.
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.
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.
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.
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.
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.
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?