Modular deployment strategies 

You manage application Branches by using the App Explorer in Dev Studio. The following figure shows an example of a Branch that a user sets up for an event booking application:

While it is not necessary to dedicate a Branch to a single Case Type, as shown in the following figure, doing so simplifies the Branch review process:

When users save a Case-related Rule in a Case-specific Ruleset to a Branch, the system generates a Case-specific Branch Ruleset if one does not already exist. Changes made in Dev Studio that affect that Rule occur in the Branch Ruleset's version of that Rule. On the creation of a Branch Ruleset, the system places it at the top of the Ruleset stack of the application, as shown in the following figure:

You initiate the merge of a single on the Branches tab of Application Explorer by right-clicking the Branch name, as shown in the following figure:

At the end of the merge process, the Branch is empty if users do not select the Keep all source Rules and Rulesets after merge option. As a result, the Branch is ready to use for the next sets of Tasks, issues, or bugs defined in Agile Studio.

Consider a scenario where 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.

The initial screen of the Application Packaging wizard prompts you for the built-on applications and the application that you want to package to include in the generated product Rule. Components are a separate concept in Pega Platform and refer to a type of Rule application where the value of pyMode property is Component. The system uses components to package reusable functionality that is sharable across multiple applications. When packaging an application with the Application Packaging wizard, you can include components as part of the package.

Multiple applications that reference the same Ruleset are highly discouraged. After you save an application Rule to a new name, warnings are displayed in both applications, one for each dual-referenced Ruleset.

The deployment strategy is different when the production application that you want to deploy depends on other multiple built-on component applications.

If the product file contains database schema changes as a part of the deployment and your organization policies do not support applying the Database schema changes automatically, you need to generate the SQL for schema changes. The database administrator manually runs the SQL before continuing with the deployment of the Rules.

In the following diagram, applications A1 and A2 undergo versioning. Application A3 is built on A1 and A2. Applications A1 and A2 are not production applications. However, applications A1 and A2 can be deployed to other development team environments, such as where application A3 is developed. It is the responsibility of application A3 responsibility to observe the version change made by applications A1 and A2. Application A3 must also decide when to change its versions to reflect the version changes under it.  

Consider the example of the FSG Booking application. The packaging of the FSGEmail application occurs first; next is the Hotel application, and then the Booking application. 

While it is possible to define a product Rule that packages only a component, it is unnecessary to do so. You can package the component by using the component Rule itself, as shown in the following figure:

Deployment Manager supports pipelines for Rule application instances where pyMode = Application and pyMode = Component. Include those components in the packaging when an application contains one or more components.

The following figure shows a component that is included in the Product Rule along with an application that uses the component. The component is EmailEditor, and the application is FSGEmail.

The goal of the Open-Closed principle is to eliminate ripple effects. A ripple effect occurs when an object changes its interface instead of 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 requires 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 must change its built-on interface so that the Booking application can supply the value for the new required property. 

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

Check your knowledge with the following interaction: