Deployment responsibilities of LSAs

The first and most important responsibility of the LSA is to ensure the security of the application. You can achieve this outcome by verifying the Security Checklist. Failure to complete the Security Checklist prevents application deployment. 

To successfully deploy application code to higher environments, the LSA must complete the following Tasks: 

• Perform a detailed assessment of the current security configuration to determine whether the settings follow best practices for application development. 
• Provide status updates on each Task on the Security Checklist page and prevent application deployment if any Task fails. 
• Stores an audit trail of the security configuration analysis and status at the time of deployment. 

The DevOps release pipeline can generate a sample error report for the Verify Security Checklist Task, as shown in the following example: 

1. SECURITY_ADMINISTRATORS : Determine who is responsible for this checklist
2. RULE_SECURITY_ANALYZER : Eliminate vulnerabilities in custom code
3. SECURITY_ALERTS : Address security alerts promptly
4. CONFIGURE_RULES : Configure rules appropriately
5. PASSWORD_POLICY : Configure authentication security policies

Please check deployment logs for the complete list of failed Tasks.

If any Tasks encounter an error, the DevOps release pipeline displays a failed status, as shown in the following figure. In this example, the Verify security checklist Task failed.

In a Deployment Manager release pipeline, the Check Guardrail Compliance Task validates the compliance score of the application during deployment. The Task returns an error if the guardrail compliance for the application is less than the configured compliance score. As a best practice, aim for a compliance score of 97 or higher for high-performing applications. 

The system blocks deployments 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 offer a more granular approach to restore points, allowing you to revert rules and data instances in a specific application. 

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

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

The following figure shows the completed rollback process for a failed deployment. The system restores the deployment to its 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.

If any problems arise during a product import for manual deployments that use the Import wizard, you can use the prpcServiceUtils tool to roll back your system to a restore point.  

Pega Platform automatically creates restore points after an archive import. When importing product files, do not select the Do not set restore point or save metadata during the import checkbox, as shown in the following figure. Otherwise, Pega Platform does not create a restore point as part of the 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 the rollback feature does not roll them back. 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 tell the system to avoid generating 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: