Deployment Strategies Cheat Sheet

Updated 2026-05-28

🧠Study flashcards on this topic111 cards · spaced repetition→

Deployment strategies are systematic approaches for releasing software updates to production environments while managing risk, minimizing downtime, and ensuring system reliability. In modern DevOps and cloud-native architectures, choosing the right deployment strategy determines how quickly teams can deliver features, how safely they can roll back failures, and how effectively they can validate changes under real production conditions. The rise of progressive delivery controllers like Argo Rollouts and Flagger, combined with supply chain security frameworks like SLSA and standardized feature flagging via OpenFeature, has dramatically expanded the deployment toolbox beyond basic rolling and blue-green patterns. Understanding this full spectrum — from foundational approaches to automated canary analysis and serverless traffic shifting — enables teams to balance velocity with stability and implement progressive delivery practices that protect user experience while accelerating innovation.

What This Cheat Sheet Covers

This topic spans 20 focused tables and 119 indexed concepts, 111 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core Deployment PatternsTable 2: Progressive Delivery TechniquesTable 3: Traffic Management and RoutingTable 4: Health Checks and ValidationTable 5: Rollback and RecoveryTable 6: Database Migration StrategiesTable 7: Deployment OrchestrationTable 8: Advanced Deployment PatternsTable 9: Deployment Gates and ApprovalsTable 10: Monitoring and ObservabilityTable 11: Risk Mitigation TechniquesTable 12: Security and ComplianceTable 13: Kubernetes-Specific StrategiesTable 14: Service Mesh Deployment FeaturesTable 15: CI/CD Pipeline IntegrationTable 16: Infrastructure as Code for DeploymentsTable 17: Configuration ManagementTable 18: Deployment Coordination PatternsTable 19: Testing in ProductionTable 20: Deployment Metrics and KPIs

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core Deployment Patterns

These are the fundamental strategies for releasing software to production. Each makes a different trade-off between downtime risk, resource cost, rollback speed, and complexity — knowing when to apply each is the first skill of a mature deployment practice.

Strategy	Example	Description
Blue-Green Deployment	Two identical environments: route 100% traffic from blue to green	• Runs two production environments simultaneously • switches all traffic instantly between versions for zero-downtime releases with immediate rollback capability.
Canary Deployment	Route 5% traffic to new version, monitor, then gradually increase to 100%	• Releases new version to small subset of users first, progressively increasing traffic while monitoring metrics • limits blast radius of failures.
Rolling Deployment	Update pods one-by-one: `maxUnavailable: 1` `maxSurge: 1`	• Default Kubernetes strategy that incrementally replaces old instances with new ones • maintains availability but runs mixed versions temporarily.
Shadow Deployment	Mirror 100% production traffic to new version without affecting responses	• Duplicates live traffic to new version for testing under real load • users receive responses only from production version while shadow version is monitored.
A/B Testing Deployment	Route 50% users to version A, 50% to version B based on user traits	• Splits traffic between versions to measure user behavior and feature effectiveness • focuses on business metrics rather than technical validation.
Ring-Based Deployment	Deploy to Ring 0 (dev team) → Ring 1 (internal) → Ring 2 (early adopters) → Ring 3 (all users)	• Progressive rollout to increasingly larger user groups • each ring acts as validation gate for next ring with defined blast radius limits.
Serverless Traffic Shifting	`aws lambda update-alias --routing-config '{"AdditionalVersionWeights":{"2":0.05}}'`	• Routes percentage of Lambda invocations to new function version via alias weights • supports canary and linear strategies through AWS CodeDeploy without managing servers.
Immutable Deployment	Replace entire server instance rather than patching in-place	• Never modifies existing infrastructure after deployment • always creates new instances from base images for consistency and predictable rollback.
Recreate Deployment	`kubectl delete deployment app` `kubectl apply -f v2.yaml`	• Terminates all old pods before creating new ones • causes downtime but ensures only one version runs at any time • suitable for breaking changes or stateful apps.

Table 2: Progressive Delivery Techniques

Progressive delivery extends continuous delivery by coupling automated metric analysis and incremental exposure with the ability to halt or roll back at any step. These techniques reduce the risk of each individual release rather than relying solely on pre-deployment testing.

Technique	Example	Description
Feature Flags (Feature Toggles)	`if (featureFlags.isEnabled('newCheckout')) {` `return newCheckoutFlow();` `}`	• Decouples deployment from release by wrapping code in conditional logic • enables runtime feature activation without redeployment.

The rest of this section is part of the full cheat sheet

Table 3: Traffic Management and Routing

Traffic management is the mechanism that makes most progressive delivery strategies possible — without fine-grained routing control, you cannot do canary or A/B testing safely. These tools and primitives sit at different layers of the stack, from DNS to service mesh.

Method	Example	Description
VirtualService (Istio)	`route:` `- destination: v1` `weight: 90` `- destination: v2` `weight: 10`	• Defines routing rules at service mesh layer for precise traffic control • enables canary, A/B testing, and fault injection without code changes.

The rest of this section is part of the full cheat sheet

Table 4: Health Checks and Validation

Deployment validation spans from basic container readiness to automated metric analysis that drives promotion or rollback decisions. The goal is to catch failures as early as possible in the rollout, before they reach the full user base.

Probe	Example	Description
Readiness Probe	`readinessProbe:` `httpGet:` `path: /ready` `port: 8080`	• Determines when container is ready to accept traffic • Kubernetes waits for readiness before routing requests to new pods during rollout

The rest of this section is part of the full cheat sheet

Table 1: Core Deployment Patterns

Strategy	Example	Description
Blue-Green Deployment	Two identical environments: route 100% traffic from blue to green	• Runs two production environments simultaneously • switches all traffic instantly between versions for zero-downtime releases with immediate rollback capability.
Canary Deployment	Route 5% traffic to new version, monitor, then gradually increase to 100%	• Releases new version to small subset of users first, progressively increasing traffic while monitoring metrics • limits blast radius of failures.
Rolling Deployment	Update pods one-by-one: `maxUnavailable: 1` `maxSurge: 1`	• Default Kubernetes strategy that incrementally replaces old instances with new ones • maintains availability but runs mixed versions temporarily.
Shadow Deployment	Mirror 100% production traffic to new version without affecting responses	• Duplicates live traffic to new version for testing under real load • users receive responses only from production version while shadow version is monitored.
A/B Testing Deployment	Route 50% users to version A, 50% to version B based on user traits	• Splits traffic between versions to measure user behavior and feature effectiveness • focuses on business metrics rather than technical validation.
Ring-Based Deployment	Deploy to Ring 0 (dev team) → Ring 1 (internal) → Ring 2 (early adopters) → Ring 3 (all users)	• Progressive rollout to increasingly larger user groups • each ring acts as validation gate for next ring with defined blast radius limits.
Serverless Traffic Shifting	`aws lambda update-alias --routing-config '{"AdditionalVersionWeights":{"2":0.05}}'`	• Routes percentage of Lambda invocations to new function version via alias weights • supports canary and linear strategies through AWS CodeDeploy without managing servers.
Immutable Deployment	Replace entire server instance rather than patching in-place	• Never modifies existing infrastructure after deployment • always creates new instances from base images for consistency and predictable rollback.
Recreate Deployment	`kubectl delete deployment app` `kubectl apply -f v2.yaml`	• Terminates all old pods before creating new ones • causes downtime but ensures only one version runs at any time • suitable for breaking changes or stateful apps.

Table 2: Progressive Delivery Techniques

Technique	Example	Description
Feature Flags (Feature Toggles)	`if (featureFlags.isEnabled('newCheckout')) {` `return newCheckoutFlow();` `}`	• Decouples deployment from release by wrapping code in conditional logic • enables runtime feature activation without redeployment.

Table 3: Traffic Management and Routing

Method	Example	Description
VirtualService (Istio)	`route:` `- destination: v1` `weight: 90` `- destination: v2` `weight: 10`	• Defines routing rules at service mesh layer for precise traffic control • enables canary, A/B testing, and fault injection without code changes.

Table 4: Health Checks and Validation

Probe	Example	Description
Readiness Probe	`readinessProbe:` `httpGet:` `path: /ready` `port: 8080`	• Determines when container is ready to accept traffic • Kubernetes waits for readiness before routing requests to new pods during rollout