Deployment responsibilities of LSAs

Deployment now blocks deployments in systems with a production level of 5 if the artifact contains draft flows. If the production level is lower than 5, a warning message is displayed in the Deployment History and Reports section, which indicates that draft flows might cause production failures.

Application-level rollbacks now provide a more granular approach to restore points, which you can use to revert rules and data instances in a specific application. This feature requires Pega Platform version 8.4 and later.

Rollback relies on the restore points feature of Pega Platform. The Rollback option is displayed to users only when a step errors out in a deployment. The system generates a restore point automatically every time an import occurs. The system rolls back any changes after the import and before any application generates the next restore point when users initiate the rollback action from the release pipeline.

The following figure shows the Rollback option that is available for the failed deployment in a DevOps release pipeline:

The following figure shows the completed rollback process the failed deployment. The system restores the deployment to the previous state in the DevOps release pipeline.

The following diagram illustrates the release pipeline and the process involved in rolling back a deployment:

1. Release Manager creates a CI/CD pipeline for an application.
2. Trigger CI/CD.
3. Publish the package to the development repository.
4. Deploy the package from the development repository to the staging environment.
5. Pega Platform creates restore points after every product deployment.
6. Run pipeline steps (compliance score, Security Checklist, and test coverage).
7. Skip and continue.
8. Publish the package to the production repository.
9. Roll back the package.
10. Get RAP with a restore point from the database.
11. Delete individual rule instances.
12. Post status update to the Release Manager.

The following log entries from the Deployment manager release pipeline are displayed when rollback occurs:

2020-11-03 07:32:02,031 [PegaRULES-Batch-3] [com.pega.pegarules.deploy.internal.restorepoint.AbstractRollback] INFO Rolling back Application using restore point - RP_20201103T073104.595_qfjj

For the manual deployments that use the Import wizard, use the prpcServiceUtils tool to roll back your system to a restore point if any problem arises during a product import.

Pega Platform automatically creates restore points after an archive import. While importing product files, do not select Do not set restore point or save metadata during the import, as shown in the following figure. Otherwise, the option enables Pega Platform to create a restore point as a part of product file import.

Limitations with restore points

There are limitations to what you can restore when you roll back. Pega Platform uses historical records to return most of the system to the restore point state. Changes to the following items do not generate history records and are not rolled back by the rollback feature. Decide on a case-by-case basis whether to remove these changes manually or whether they can remain on the system.

• SQL changes
• JAR imports
• Some custom data instances

When you configure the class for a data type, you can specify not to generate a history record for instances of that type. If the data instance does not generate a history record, you cannot roll back changes to the data instance.
You can specify which rule and data instances return to the previous state:

• System: Roll back every rule and data instance with a historical record; System is the default setting.
• User: Rollback rule and data instances that a specific user modified. 
  Note: If more than one user changes any rule, you see an error message and must use the system rollback.
• Application: Rollback rule and data instances in a specific application.

For more information about restore points, see Using restore points to enable error recovery.

Check your knowledge with the following interaction: