Deployment design patterns
Delivering applications effectively is as critical as designing them. In a DevOps-driven environment, success depends on more than speed. It requires an architecture that supports continuous delivery from the start. Pega deployment design patterns provide foundational, reusable solutions that enable reliable, scalable, and automated deployments.
Unlike high-level deployment strategies such as Blue/Green or Canary releases, which define when and how releases occur, design patterns focus on how the architecture supports packaging, configuring, and managing applications for operational excellence. By adopting these patterns early, your applications become modular, configurable, and ready for automation. This approach bridges the gap between design and delivery in a modern DevOps environment.
Key deployment design patterns
Deployment design patterns fall into two categories:
- Patterns that shape the automation pipeline.
- Patterns that define infrastructure and application architecture.
Pipeline automation patterns
Use pipeline automation to standardize and accelerate deployments. The following features help you achieve consistent, repeatable processes:
- Automated deployment pipeline (CI/CD): Create a fully automated, end-to-end process for building, testing, and deploying applications. In Pega Platform™, use Deployment Manager or integrate orchestration APIs with tools such as Jenkins or Azure DevOps. The pipeline promotes application artifacts through quality checks and environments (Development → QA → Staging → Production) to support a repeatable and reliable release process with minimal manual intervention.
- Configuration-as-code: Manage environment-specific settings (such as database connections or integration endpoints) in version-controlled text files (YAML or properties files). During deployment, apply the correct configuration file for the target environment to eliminate errors.
- Modular deployment design: Architect the application with a modular structure using distinct Rulesets and built-on layers. This approach helps you achieve parallel development and independent deployment of components. Plan the application hierarchy and dependency model to support smaller, safer releases.
Architectural and infrastructure patterns
Architectural and infrastructural choices define how applications scale and perform. The following elements ensure a stable foundation for deployment:
- Containerized deployment: Package Pega Platform and its node types (Web, Batch, Stream) into Docker containers managed by Kubernetes. This approach supports consistency across environments and enables automated scaling and self-healing. Deploy node types as separate containers in Pods for resource isolation.
- Declarative deployment: Use declarative configuration files (such as Helm charts) to define the desired state of the Pega Platform environment. The orchestrator enforces the desired state and simplifies upgrades and rollbacks.
- Immutable infrastructure: Replace environments instead of modifying them. Deploy new containers with updated versions and decommission old ones. This approach removes configuration drift and simplifies rollbacks.
- Sidecar pattern: Deploy auxiliary services (logging, monitoring, security agents) in separate containers alongside the main application container within the same Pod. This approach enables updates to cross-cutting concerns without changing the core application.
- External configuration store: Store configuration data in centralized services (for example, Kubernetes ConfigMaps, Azure App Configuration, or AWS Systems Manager Parameter Store). Configure the application to fetch settings from this store at startup, making deployment artifacts universally applicable.
- Deployment stamps: Provision multiple independent, identical copies of the Pega stack ("stamps"). Use this for multi-tenancy, regional isolation, or fault domains. Pega Cloud® uses this pattern to provide dedicated stamps for each customer.
The deployment design patterns in the following table provide reusable solutions for reliable and scalable application delivery. Each pattern includes its primary goal, key benefits, and guidance on when to use it in Pega environments:
| Pattern | Primary goal | Key benefit(s) | When to use in Pega |
|---|---|---|---|
| Automated pipeline | Automate the end-to-end release process. | Speed, reliability, repeatability. | Universal. This is the foundation of any modern Pega DevOps practice. |
| Containerized deployment | Package Pega Platform for portability and consistency. | Consistency across environments, scalability. | Standard for all new Pega Platform deployments (Pega Cloud or on-premise Kubernetes). |
| Immutable infrastructure | Ensure consistency by replacing environments. | Eliminates configuration drift, simplifies rollbacks. | Default for containerized Pega Platform deployments on Kubernetes. |
| Modular deployment | Enable independent development and deployment. | Parallel development, smaller/safer releases. | For large, complex applications with multiple teams or business functions. |
| External configuration store | Decouple the application from the environment settings. | High flexibility, enhanced security. | Best practice for all enterprise-grade Pega Platform deployments, especially in the cloud. |
| Deployment stamps | Create isolated, independent copies of the Pega stack. | Multi-tenancy, data residency, fault isolation. | For SaaS offerings built on Pega Platform, or for global deployments with strict regional requirements. |
Check your knowledge with the following interaction: