Deployment responsibilities of LSAs

Effective deployment begins in the design phase, long before you run a pipeline. As an architect, shift deployment planning by embedding deployability into the application architecture with tools such as Blueprint.

Blueprint promotes deployability through three practices:

• Architect for modularity: Use Blueprint to design an enterprise class structure (ECS) and loosely coupled application components that can be deployed independently. This approach reduces risk and complexity, enabling faster, targeted releases.
• Incorporate strategy early: Define and document the branching strategy, testing approach, and data management plan during design. Blueprint translates these strategies into assets and documentation, ensuring the development team starts with a deployable architecture.
• Automate asset generation: Use Blueprint to generate application assets that follow DevOps best practices from day one. This reduces manual configuration and ensures consistency across environments.

An LSA does not wait until the end of a release to check security; You embed security practices throughout the development lifecycle. The deployment pipeline should validate these practices automatically, not as the first line of defense.

Security checklist as an automated audit

Use the Security Checklist in Pega Platform™ as a critical tool and automated gate in your deployment pipeline. The pipeline must stop if any security task fails.

As an LSA, you are accountable for:

• Ensuring the development team understands and addresses each checklist item during sprints.
• Performing detailed assessments of security configurations against best practices.
• Analyzing and resolving any failed tasks reported by the pipeline.

The DevOps pipeline provides clear feedback when a violation occurs, preventing insecure code from progressing.

The following example shows a pipeline error when the Security Checklist gate fails:

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

Check deployment logs for the complete list of failed Tasks.

A successful deployment is more than moving code to production. It ensures the application is healthy, maintainable, and cost-effective to run and update.

Guardrail compliance as a health indicator

The guardrail compliance check in the pipeline is more than just a gate; it measures the long-term health of the application. While the best practice is a compliance score of 97 or higher, your role as an LSA is to:

• Interpret the score: Understand the business impact of the remaining warnings.
• Prioritize technical debt: Work with the product owner to prioritize resolving significant guardrail violations in the backlog.
• Justify exceptions: Document and justify any critical exceptions to avoid compromising future updateability or performance.

Ensuring production readiness

The pipeline enforces production readiness rules. For example, the system blocks deployments to a production environment (production level 5) if the artifact contains draft flows. Draft flows indicate incomplete development and can cause critical failures.

Flawless deployments are the goal, but a robust recovery plan is essential. As an LSA, you design and maintain the recovery strategy to ensure application resilience. This responsibility goes beyond a simple rollback.

Rollback versus roll-forward

When a deployment fails, your recovery strategy should consider the following options:

• Rollback: Determine whether the issue is significant enough to require reverting to a previous stable state. This option is the safest for complex or critical failures. 
• Roll forward: Determine whether the issue is minor and can be resolved with a targeted hotfix. This option can be faster but requires a confident diagnosis of the problem.

Automated rollback with restore points

Pega Platform creates restore points automatically during every import. If a pipeline step fails, the rollback option becomes available and the system returns application rules and data to the last known good state.

The rollback process involves identifying the correct restore point and using historical records to revert the changes made during the failed deployment.

Automated rollbacks have limitations. Your recovery plan must account for items that are not automatically reverted. You must decide whether to remove these manually or confirm that they can remain safe.

Items that are not rolled back automatically include:

• SQL changes (schema modifications)
• JAR imports
• Custom data instances where history is not enabled

For manual deployments, you can use the prpcServiceUtils tool to initiate a rollback to a restore point. When importing manually, do not select the Do not set restore point option, because this action disables your primary recovery mechanism.

As Pega applications incorporate AI and decisioning, your deployment strategy must include managing the lifecycle of AI models.

Managing AI-powered deployments requires a clear strategy that addresses: 

• Model versioning: Package and version AI models (Predictive, Adaptive, and Text Analytics) along with your application code. Your deployment strategy must ensure that the correct model version is active in the appropriate environment.
• Data and schema dependencies: Ensure that the data schemas, properties, and reference data required by your AI models are deployed and versioned in lockstep with the models.
• Monitoring and retraining strategy: A deployed model is not static. Define the post-deployment strategy for monitoring model performance (such as accuracy degradation or prediction drift) and establish a process for retraining and redeploying models with minimal business disruption.

In a cloud-native context (for example, Kubernetes), the responsibilities of the LSA expand to include the application's interaction with its environment.

Cloud-native deployment and observability require attention to the following key areas:

• Containerization strategy:
• Define how the Pega application is configured and packaged into containers. Specify resource requests and limits, manage environment-specific configurations, and ensure secure communication.
• Design for scalability: Architect application components, especially background processors such as queue processors, to take advantage of auto-scaling and self-healing features in the cloud platform. This approach ensures that your application is resilient and cost-efficient.
• Engineer for observability: Go beyond basic logging by including:  
  • Structured logging: Generate logs in a consistent, machine-readable format (for example, JSON) for ingestion by analysis tools.
  • Health endpoints: Configure readiness and liveness probes that the cloud platform uses to manage the application lifecycle.
  • APM integration: Integrate your application with Pega Diagnostic Center and other application performance monitoring tools to provide detailed insight into performance and user behavior.

Check your knowledge with the following interaction: