Deployment responsibilities of LSAs
As a Lead System Architect, you play a critical role in ensuring that the deployment of Pega Platform™ applications is correct, secure, and efficient. Your responsibilities related to deployment include planning and coordinating deployment, configuring deployment settings, managing deployment packages, troubleshooting deployment issues, ensuring compliance with deployment policies, and providing guidance and support to the development team.
Lead System Architects (LSAs) have varying responsibilities when deploying application code to higher environments, depending on the culture of an organization.
Verification of the Security Checklist
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:
Error encountered in Verify Security checklist gate 34/34 Tasks are incomplete.<br />
Please log into development environment and complete all Tasks in the Application Guide: Application security checklist. <br />
Failed Tasks:
Please log into development environment and complete all Tasks in the Application Guide: Application security checklist. <br />
Failed Tasks:
SECURITY_ADMINISTRATORS : Determine who is responsible for this checklist
RULE_SECURITY_ANALYZER : Eliminate vulnerabilities in custom code
SECURITY_ALERTS : Address security alerts promptly
CONFIGURE_RULES : Configure rules appropriately
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.
Draft flow cross-check
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 rollback to a restore point
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:
- Release Manager creates a CI/CD pipeline for an application.
- Trigger CI/CD.
- Publish the package to the development repository.
- Deploy the package from the development repository to the staging environment.
- Pega Platform creates restore points after every product deployment.
- Run pipeline steps (compliance score, Security Checklist, and test coverage).
- Skip and continue.
- Publish the package to the production repository.
- Roll back the package.
- Get RAP with a restore point from the database.
- Delete individual rule instances.
- Post status update to the Release Manager.
Manual deployment with restore points to enable error recovery
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:
This Topic is available in the following Module:
If you are having problems with your training, please review the Pega Academy Support FAQs.
Want to help us improve this content?