Authored by: Pallavi Gurram
Best practices
This document provides application deployment best practices for Pega Platform developers and release managers. The list of best practices collates Pega application deployment experiences from lead system architects and release managers.
The list below categorizes the best practices by their application impact if you do not follow the Continuous Integration and Continuous Delivery (CI/CD) guidelines.
Note: This list remains up-to-date as we receive new best practices recommendations.
| Impact | Check | Details | Prevents | How to verify? | Priority |
|---|---|---|---|---|---|
| Functionality | Unit test pass rate per application | Ensure that unit test pass rate is equal to 100%. | Breaking of any known unit-level functionality, ensuring successful execution of all unit tests. | AQD Dashboard / AQD Metrics API | High |
| Scenario test pass rate per application | Ensure that scenario test pass rate is equal to 100%. | Breaking of any known application-level functional scenarios by ensuring successful execution of all scenario tests. | AQD Dashboard / AQD Metrics API | High | |
| Test coverage | Ensure the test coverage of all executable rules => 70%
(100% is recommended). |
Unexpected exceptions or failures by ensuring client application is comprehensively tested (meeting the defined benchmark) and all deployed functionality is reachable. | AQD dashboard / AQD Metrics API | Medium | |
| Ensure the test coverage of all executable rules per each case type and data type => 70% (100% is recommended). | Unexpected exceptions or failures by ensuring all the case types & data types are tested to prescribed benchmark. | AQD Dashboard | Medium | ||
| Ensure that the test coverage of all decision rules => 70% | Unexpected exceptions or failures by ensuring all decision rules have been covered to the defined benchmark. | AQD Dashboard | Medium | ||
| All case types and user operator types are exercised at least once. | Ensure that each case type has at least one instance created and each user type is logged in at least once. | Unexpected exceptions or failures ensuring all possible case and user types are exercised and verified at least once. | Not available | Medium | |
| Exceptions in logs during testing | Ensure that there are no exceptions generated for a specific period. | Unexpected behavior of the application and any potential failures. | Go to System-> Operations-> Logs and check Pega logs for errors. PDC can be leveraged to look for exception logs. | High | |
| Reliability | Application guardrail score | Ensure that the application guardrail score is > 85% (90% is recommended), and that there are 0 severe warnings. | Exceptions and unexpected behavior of the application. | AQD Dashboard in the application / Guardrail API or AQD Metrics API. | High |
| Missing rule references | Ensure that there are no missing rules that are referenced by the application. | Application issues or any failures due to not finding required rules during execution. | Dev studio has a built-in capability to perform validation at the application and ruleset level, which provides a list of missing rules.
Run revalidate wizard to learn about invalid rules and fixing them immediately enhances application stability. Rigorous and periodic code review should help reduce invalid rules |
Medium | |
| Draft flows | Ensure that your application does not contain any draft flows. | Run time performance impact. | Deployment Manager automatically performs this check before deploying to production. This API can be leveraged to verify this. | High | |
| Aged updates | Ensures that only the latest rules are moved to production and stop/alert if production already has a later version.
Aged updates should not be allowed unless explicitly reviewed and signed off. |
Accidental moving of incorrect rule versioning to higher environments. | Import wizard shows this info while importing. Deployment Manager alerts the user. | High | |
| Bypass overriding environment setting | Ensure environment-specific configurations are not overridden due to RAPs imports in higher environments. To do this, utilize the bypass feature of a product rule. | Including required classes from updating environment-specific settings. | Manual verification is required. | Medium | |
| Branch reviews | Ensure branch reviews are captured and only reviewed branches can merge. | Locking of the target application and ruleset. Development should only be allowed in develop branches and add gates to review branches before merge. | From Dev Studio review tab. | Medium | |
| Incremental delivery | Practice continuous integration of code using the platform branch merge capability. | Locking of the target application and ruleset. Development should only be allowed in develop branches and deliver code to higher environments via branch merges. | Review with release manager/lead architect. Branch merges should be enabled. | Low | |
| Application and ruleset versioning | Applications should point to rulesets with major and minor version omitting patch version.
Increment the application and ruleset patch version each time you deploy changes to a production system. As a best practice, use semantic versioning. This will add the advantage of allowing rollbacks in production by only modifying access groups. |
N/A | This has to reviewed by release manager/Lead architect. | Medium | |
| Ensure database changes are promoted to higher environments | Ensure appropriate DADTs are explicitly added to product rules, moving required database changes to higher environments successfully. | N/A | Manual verification is required post-deployment using schema tools in Dev Studio. Whenever a new class is being introduced, this verification should be performed. | Medium | |
| Maintainability | Deprecated rules (potential update impact) | Ensure that your application does not contain any deprecated rules | Compatibility issues that may arise during future platform updates, as there will not be any platform support for such rules. | Not available | High |
| Overridden rules (potential update impact) | Ensure no Pega supplied rules are overridden. Only extensions provided by Pega should be used. | Future updates and maintenance issues when platform updates and customers have overridden some of the Pega rules | Go to Application->Development->Rule Overrides and verify the overrides by selecting appropriate rulesets. | High | |
| App studio compliance (non auto-generated controls, custom HTML) (potential update impact) | Ensure there is no custom HTML or non auto-generated controls in the application. | Usage of unsupported/ non autogenerated controls, custom HTML, other UI compliance and avoids compatibility issues. | Go to Application->Quality->App Studio Compliance and verify for UI compliance. | Medium | |
| Tests or test data should not be moved to production | Production ready code should not contain tests or test data. | Test applications/rulesets being promoted to production. Test application should be built-on a main application so that test rules are independent from the actual application and only the actual application can be promoted to production. | Manual verification from Dev Studio. | Medium | |
| No branches are promoted to higher environments | Target application should not contain code in branches. | Migration of development branches across higher environments. | Manual verification from Dev Studio. | Medium | |
| Componentization | Componentize application layers so that independent components are delivered to production adhering to a common release.
Sharing application-based rulesets across applications would lead to maintenance issues and reduce re-usability. Consider configuring Ruleset into appropriate Application rule to simplify maintenance and improve re-usability. If required create a separate ruleset for different application based on the requirement for specialization. If any application rule is no longer used, consider deleting the rule. |
N/A | Manual verification from Dev Studio. | Low | |
| Efficiency | Go / No-Go From PDC | Pega Predictive Diagnostic Cloud™ (PDC) can monitor your application performance and diagnose system health issues. Use PDC to identify and correct these issues quickly and minimize their impact on your business.
To only receive the measurements that are relevant and useful for you, determine what data you need to receive on a regular basis, what information is only useful when troubleshooting a specific issue, and who should receive this information. |
Slippage of performance and security issues. | Log in to PDC and verify. Configure the QA machine with PDC to get all the alerts while testing. | High |
| Security | Secured service packages | All services making external calls must be secured using TSL. | Security breaches & issues | Go to Dev studio > Resources >Application guides > Application Security Checklist and perform the security checks.
(NOTE: Security checklist covers most of this manually.) |
High |
| Roles & privileges to restrict access | Access restriction for the applications. | High | |||
| Access control policies to restrict access | High | ||||
| Data encryption | Encrypt all sensitive data. | High | |||
| System production level should be 5 for production | Required value for production applications. | High | |||
| Locked application & rulesets | No unlocked application or ruleset to be deployed into production. | High | |||
| No checked out rules to be deployed | Checked out rule report landing page and report. | Medium | |||
| No development operator rules to production | Block any unnecessary roles or operators to go to production from development. | Medium | |||
| Secure passwords | All passwords must be securely hashed and stored. | High | |||
| Define Cross Site Request Forgery settings | CSRF Settings landing page (Manual). | Medium | |||
| Define content security policies (CSPs) | A production application must have CSPs specified to inform user's browser of locations from which an application is allowed to load resources. | Medium | |||
| Define CORS policies for REST services | Define these policies to control and secure access to REST services in your application by external systems. | Medium | |||
| Configure appropriate logging levels | Log level must be set to INFO or lower to reduce security risks. | Low | |||
| Traceability | Change impact tracking | Associating work bench item with every deployment/merge will provide better traceability of change impact. | Prevents unwanted functionality moving to production | Not applicable |