Backend Deployment Cheat Sheet

Updated 2026-05-28

Next Topic: Backend Development Cheat Sheet

🧠Study flashcards on this topic102 cards · spaced repetition→

Backend deployment is the process of moving application code from development to production environments, a critical transition where planning, automation, and risk management converge. Modern deployment practices emphasize zero-downtime releases through strategies like blue-green and canary deployments, progressive delivery that incrementally exposes changes to users, and automated rollback mechanisms that restore service when issues arise. Understanding these patterns — from database migration techniques to supply chain security controls — separates deployments that cause outages from those that ship reliably at scale.

What This Cheat Sheet Covers

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

Table 1: Core Deployment StrategiesTable 2: Zero-Downtime TechniquesTable 3: Traffic Management & ShiftingTable 4: Database Migration During DeploymentTable 5: Rollback StrategiesTable 6: Feature Flags & TogglesTable 7: CI/CD Deployment AutomationTable 8: Container Orchestration & Package ManagementTable 9: Deployment Verification & TestingTable 10: Deployment Monitoring & ObservabilityTable 11: Environment Management & PromotionTable 12: Supply Chain Security & Deployment GovernanceTable 13: Advanced Deployment Patterns

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 Strategies

The choice of deployment strategy determines how risk, downtime, and blast radius are controlled when shipping new code. Ordered from the simplest to the most controlled, each strategy trades off speed, complexity, and rollback capability differently.

Strategy	Example	Description
Blue-Green Deployment	Two environments: Blue (live) and Green (new). Traffic switches instantly after validation.	• Maintains two identical production environments to eliminate downtime • instant rollback by reverting traffic to the previous environment.
Canary Deployment	Route 5% traffic to new version. Monitor metrics, then gradually increase to 100%.	• Gradually shifts traffic to new version starting with small percentage • limits blast radius if issues arise and enables real-world validation.
Rolling Update	Replace pods incrementally: 25% → 50% → 75% → 100%. Old and new versions coexist temporarily.	• Replaces instances incrementally without downtime • both versions run simultaneously during transition, requiring backward compatibility.
Progressive Delivery	Release to internal users → beta testers → 10% → 50% → 100%. Gate each phase on metrics passing thresholds.	• Controlled, incremental rollout with automated promotion based on success criteria • combines feature flags, canary releases, and observability.
Dark Launch	Deploy feature to production with feature flag disabled. Enable for internal team first, then gradually.	• Code is deployed but feature remains hidden behind toggle • allows production testing without user visibility before official release.
Shadow Deployment	Mirror production traffic to new version. Compare responses without affecting users.	• New version processes real traffic in parallel with production but results are not served to users • validates performance and behavior without risk.
A/B Testing Deployment	Route 50% users to variant A, 50% to variant B. Measure conversion, engagement, latency.	• Different versions served to user segments for business metric comparison • feature effectiveness measured before full rollout.
Recreate Deployment	Terminate all running instances. Deploy new version after complete shutdown.	• All existing instances are stopped before new ones start • accepts downtime in exchange for simplicity, suitable for dev environments or breaking changes.
Deployment Stamp Pattern	Deploy to Stamp A, validate, then deploy to Stamp B. Each stamp is an independent production unit.	• Blue-green at the infrastructure stamp level — deploy new version to one stamp while others serve traffic • naturally limits blast radius across regions or tenants.

Table 2: Zero-Downtime Techniques

Zero-downtime deployment is not a single technique but a combination of application behaviour, orchestration configuration, and traffic management. These patterns address the handoff period when old and new versions coexist on the same cluster.

Technique	Example	Description
Graceful Shutdown	On SIGTERM: stop accepting new requests. Wait for in-flight requests to complete. Close connections, then exit.	• Process finishes active work before terminating • prevents dropped requests during pod replacement or scaling down.

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

Table 3: Traffic Management & Shifting

Controlling which traffic flows to which version is the operational core of canary and blue-green deployments. These techniques give teams precise control over blast radius, user targeting, and the speed of a rollout.

Technique	Example	Description
Weighted Traffic Splitting	Route 90% to v1, 10% to v2. Gradually shift: 70/30, 50/50, 0/100.	• Distributes requests across versions by percentage • controlled exposure enables gradual validation and safe rollout.

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

Table 4: Database Migration During Deployment

Database changes are the hardest part of zero-downtime deployment. These patterns decouple schema changes from code changes so that both old and new application versions can coexist on the same database without breaking.

Pattern	Example	Description
Expand-Contract (Expand-Migrate-Contract)	1. Add new column (Expand) 2. Dual-write to both columns 3. Backfill data (Migrate) 4. Remove old column (Contract)	• Three-phase approach for schema changes without downtime • maintains backward compatibility by supporting both old and new schemas temporarily.

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

Table 1: Core Deployment Strategies

Strategy	Example	Description
Blue-Green Deployment	Two environments: Blue (live) and Green (new). Traffic switches instantly after validation.	• Maintains two identical production environments to eliminate downtime • instant rollback by reverting traffic to the previous environment.
Canary Deployment	Route 5% traffic to new version. Monitor metrics, then gradually increase to 100%.	• Gradually shifts traffic to new version starting with small percentage • limits blast radius if issues arise and enables real-world validation.
Rolling Update	Replace pods incrementally: 25% → 50% → 75% → 100%. Old and new versions coexist temporarily.	• Replaces instances incrementally without downtime • both versions run simultaneously during transition, requiring backward compatibility.
Progressive Delivery	Release to internal users → beta testers → 10% → 50% → 100%. Gate each phase on metrics passing thresholds.	• Controlled, incremental rollout with automated promotion based on success criteria • combines feature flags, canary releases, and observability.
Dark Launch	Deploy feature to production with feature flag disabled. Enable for internal team first, then gradually.	• Code is deployed but feature remains hidden behind toggle • allows production testing without user visibility before official release.
Shadow Deployment	Mirror production traffic to new version. Compare responses without affecting users.	• New version processes real traffic in parallel with production but results are not served to users • validates performance and behavior without risk.
A/B Testing Deployment	Route 50% users to variant A, 50% to variant B. Measure conversion, engagement, latency.	• Different versions served to user segments for business metric comparison • feature effectiveness measured before full rollout.
Recreate Deployment	Terminate all running instances. Deploy new version after complete shutdown.	• All existing instances are stopped before new ones start • accepts downtime in exchange for simplicity, suitable for dev environments or breaking changes.
Deployment Stamp Pattern	Deploy to Stamp A, validate, then deploy to Stamp B. Each stamp is an independent production unit.	• Blue-green at the infrastructure stamp level — deploy new version to one stamp while others serve traffic • naturally limits blast radius across regions or tenants.

Table 2: Zero-Downtime Techniques

Technique	Example	Description
Graceful Shutdown	On SIGTERM: stop accepting new requests. Wait for in-flight requests to complete. Close connections, then exit.	• Process finishes active work before terminating • prevents dropped requests during pod replacement or scaling down.

Table 3: Traffic Management & Shifting

Technique	Example	Description
Weighted Traffic Splitting	Route 90% to v1, 10% to v2. Gradually shift: 70/30, 50/50, 0/100.	• Distributes requests across versions by percentage • controlled exposure enables gradual validation and safe rollout.

Table 4: Database Migration During Deployment

Pattern	Example	Description
Expand-Contract (Expand-Migrate-Contract)	1. Add new column (Expand) 2. Dual-write to both columns 3. Backfill data (Migrate) 4. Remove old column (Contract)	• Three-phase approach for schema changes without downtime • maintains backward compatibility by supporting both old and new schemas temporarily.