I have some queries regarding App Build exam deployment process..

Could you please advise which approach will be best suit here for App build deployment process?

Please find below the same:

1. Deployment: Suppose a candidate gets Two different improvements (A and B ) to implement on top of Application (example: App1) provided in the exam. Leave the base version as it is (01-01-01) locked for all below scenario.

Scenario#1: All the improvements will be implemented in the same Pega instance (Linux Lite1). For each improvement implementation, a new Ruleset Version (Patch version) will be created.

Example:

• Improvement A –
  • 01-01-02 (RSV) created for existing rulesets.
  • Update the Existing application (App1) with Component rule as per requirement (for example).
  • Take the product ZIP with RSV 01-01-02 , Data instances and updated existing Application rule instance (App1)
  • Deployment Folder of Improvement(A) contains - App Build Starting point RAP file and solution RAP file.

• Improvement B –
  • 01-01-03 (RSV) created for existing rulesets.
  • Do not need to update the Existing application with newly created RSV for existing Rulesets since Only up to Minor version of RSV (01-01) will be pointed in the existing application (App1) .
  • Take the product ZIP (solution RAP file) with RSV 01-01-02 , 01-01-03 and Data instances.
  • Deployment Folder of Improvement(B) contains - App Build Starting point RAP file and solution RAP file.
  • Here candidate will add both RSV 01-01-02 , 01-01-03 in the product ZIP so that examiner could deploy and test them independently even if there are rule dependencies between Improvement. A and B.

Pros:

• Rule dependencies among improvements could be handled easily. Means, Improvement B can access rules of Improvement A.
• RAP files will support deployment and test in the same environment as well as in the separate environment for Improvements- A and B.

Cons:

• Multiple Ruleset Versions to maintain.
• Improvement A might need to customize an OOTB rule (Rule1). Improvement B does not need any customization in Rule1.

This will create an issue in improvement B since it will access improvement A’s RSV and customized Rule1 (in improvement A) will be referred in rule resolution instead of OOTB Rule1.

Scenario#2: Decouple Improvement A and B into two different Pega instances.

Example:

• Improvement A –
  • App Build Starting point RAP file imported into Pega1 (LinuxLite1)
  • 01-01-02 (RSV) created for existing rulesets.
  • Update the Existing application (App1) with Component rule as per requirement (for example).
  • Take the product ZIP with RSV 01-01-02 , Data instances and updated existing Application rule instance (App1)
  • Deployment Folder of Improvement(A) contains - App Build Starting point RAP file and solution RAP file.

• Improvement B –
  • App Build Starting point RAP file imported into Pega2 (LinuxLite2)
  • 01-01-02 (RSV) created for existing rulesets.
  • Do not need to update the Existing application with newly created RSV for existing Rulesets.
  • Take the product ZIP with RSV 01-01-02 and Data instances.
  • Deployment Folder of Improvement(B) contains - App Build Starting point RAP file and solution RAP file.

Pros:

• Easy maintenance of single RSV (01-01-02) in different Pega instances.
• NO impact of improvement A to improvement B implementation and vice versa if deployed and tested in separate Pega envs.

Cons:

• Both improvements CANNOT be tested in the same Pega environment because they are having same rulesets and versions.

So same rules could be overridden and might create some unseen problems since implementation done in two separate env.

Improvement A cannot access rules of Improvement B if there is any requirement like this.

• Multiple Pega instances to import and manage.