Parallel development through PEGA Rulesets for PEGA CSSA

This branching ability is particularly helpful when teams need to work under the same rules concurrently, and all participants of one team need to see the work of each other, while still isolating their changes in creation from other teams. In this way, once the modifications are secure, disputes resolved, and permission is given to make the new roles accessible to the entire development project team, one team’s rule changes do not impact the other teams. In this article, we will look after the parallel development via Pega rulesets.

To get in-Depth knowledge on Pega cssa you can enroll for a live demo on Pega cssa training.

Phase 1:

Create a team application based on the primary application

Typically, team applications are called in a way that represents the base application, team name, or team emphasis. For example, the name of the team application could be something like OnboardCoolPortalFeature for a base application called NewHireOnboard and Team-A development team that works on a feature that includes the layout of their user portal.

Create a new application rule in Application Explorer by right-clicking the category Application Description and selecting New > Application from the context menu. Enter the name of the team application (like OnboardCoolPortalFeature) in the new form that opens, and save it to the available RuleSet. (You can use the Advanced tab in its rule form to change the RuleSet for the application. It has no impact on the team using branches for development.) The Application Rule Form is shown in the Designer Studio.

Update the Built on Framework and Version fields in the Application rule type to reference the main base application. Click the Parent Inclusion checkbox.

By clicking the next button, delete the empty Framework PEGA Rulesets list lines. Before saving the rule form, make sure there are no entries specified for Application PEGA Rulesets.

Take your career to new heights of success with the Pega cssa course

Save the Team Framework Application Rule.

Example: The Team Framework Application Rule:

For Team Application Rule Form

In the rule type, a message appears to inform you that the applicable rule is saved to a RuleSet that is not part of the RuleSet list in the application. For a team creation application, this situation is appropriate. You may use the Justify Alerts connection to delete the display of an alarm.

Step 2:

Allow members of the team access to the application for the team

For instance, for a team application called OnboardCoolPortalFeature: for example,

Develop an access group that references the application for the team. The access group’s typical name uses the name of the application plus the default user type, such as OnboardCoolPortalFeature: Administrators.

Ensure that the Access Category is:

Using access roles that are sufficient for your application to be created and evaluated. (These may be the same ones that are defined for the base application in the access group.)

For the main program, reference the job pool.

Set the default portal layout field to the portal that you want to use while designing team members in the branches (typically the Developer portal rule).

Update the operator ID of a team member to include the access category.

Move to the team application either by using Application > Switch Application (if you have attached an access group to your operator ID) or by logging out of the system and logging into the team application using one of the access group IDs of the operator group (if you did not add the access group to your own operator ID).

Phase 3: In the team application, build the branches

Using the Branch list on the General tab of the application rule form for the team application, you build the development branches. In order to establish a branch:

Select Add Branch in the General tab of the Application Rule. This opens the Add a Branch ID window.

Type a name for a new branch in the Add Branch ID window, and then click OK to add it to the Branch list.

The best practice for the name is to connect it to the planned development work in that division. For example, you might base the branch name on that identifier, such as FeatureABC, when you use a project management tool to organize scheduled upgrades by identifier.

The device adds a branch to the list of divisions. Save the Rule for use. (If an initial row has been re-displayed by the device in the Application PEGA Rulesets list, delete it by clicking, then save the rule.)

Get hands-on experience on PEGA CSSA with expert knowledge through the Pega csa training at Onlineitguru.

In the framework law, by using different branches.

Make sure that the order of the branches in the Branch list matches the order in which the rules for users of this development application should be resolved (the developers on the team). The framework assembles the developer’s RuleSet list and the PEGA Rulesets branch according to the order in which the branches are specified in the Branch list when a developer logs into this development program. In the Branch list, to set the desired order, you may drag and drop the branches.

Step 4: Build the PEGA Rulesets branch for branches

Before you build the RuleSet branch, the creation application must have at least one branch. In the main (base) program or any of its built-in applications, the RuleSet branch is ‘branched from’ the RuleSet. The team decides which PEGA Rulesets include the rules for a proposed improvement they intend to change and establishes the PEGA Rulesets division based on those PEGA Rulesets.

In the Team Application Application Rule, on the General tab:

Press Build RuleSet Branch. Opening of a New Type.

Leave the selected checkbox for Branch RuleSet. Select the branch you want to associate this RuleSet branch with, and then select the relevant RuleSet database.

Select Building.

The RuleSet type opens the framework for the RuleSet branch. On the RuleSet form, click to save the RuleSet branch to the method.

The name of the RuleSet branch is described as a combination of the name of the RuleSet base from which it is branched and the name of the branch. Just one edition of RuleSet exists for the RuleSet branch. By default, you pick the Use check-out check box. (To use check-out and check-in while forming teams is a best practice.)

Repeat steps 1–3 to establish the PEGA Rulesets branch for all the key PEGA Rulesets containing rules that are required to be changed by the team in that branch.

Confirm that the RuleSet branch is connected to the development branch by opening a Team Framework Rule Form. Expand the branch that you have chosen for the PEGA Rulesets branch in the Branch array. The entire PEGA Rulesets branch associated with that branch is shown.

Example: Saving a copy of a flow rule within the branch of Pega RuleSet

When working in a branch, use the connection in the All Rules column in the RuleSet branch form to see which rules are in the RuleSet branch. You can open the RuleSet by clicking on its branch name in the Branch list. Then, in the All Rules column, press the number shown to see the list of rules that it includes, and drill down to see the rules.

As this team deals on rules in its branches from shared PEGA Rulesets (foundation PEGA Rulesets), other teams work on rules in their branches from the base PEGA Rulesets. When detecting whether a merge conflict could occur when the rule is merged from the branch into the base RuleSet.

Conclusion

The system displays an alert in a rule form so that the team can proactively determine what conflict resolution may be required before the merge operation. You can learn more about parallel development through PEGA CSSA online training.