Deployment Strategies

Deployment Strategies — Deployment Strategy Catalog

A reference of deployment strategies, rollback procedures, health checks, and DORA metrics used by the pipeline-designer agent when designing deployment pipelines.

Target Agent

pipeline-designer — Directly applies the deployment strategies and rollback patterns from this skill to pipeline design.

Deployment Strategy Comparison

Strategy Details

1. Rolling Update (Sequential Replacement)

Server pool: [v1] [v1] [v1] [v1]
Step 1:      [v2] [v1] [v1] [v1]  -- 1 replaced
Step 2:      [v2] [v2] [v1] [v1]  -- 2 replaced
Step 3:      [v2] [v2] [v2] [v1]  -- 3 replaced
Step 4:      [v2] [v2] [v2] [v2]  -- Complete

Configuration parameters:

• maxUnavailable: Maximum instances to take down simultaneously (1 or 25%)
• maxSurge: Maximum instances to add simultaneously (1 or 25%)

Kubernetes example:

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1

Pros: Minimal extra infrastructure, gradual replacement Cons: v1+v2 coexistence period (requires compatibility)

2. Blue-Green Deployment

Blue (current):  [v1] [v1] [v1]  <- 100% traffic
Green (standby): [v2] [v2] [v2]  <- 0% traffic

Switch:
Blue:   [v1] [v1] [v1]  <- 0% traffic (standby/remove)
Green:  [v2] [v2] [v2]  <- 100% traffic

Procedure:

1. Deploy new version to Green environment
2. Run smoke tests/health checks on Green
3. Switch load balancer traffic to Green
4. Monitor Blue environment (rollback standby)
5. After stabilization, remove Blue or hold for next deployment

Rollback: Re-switch load balancer to Blue (within seconds)

3. Canary Deployment

Step 1: [v1 x 95%] [v2 x 5%]   -- Start with 5% traffic
Step 2: [v1 x 80%] [v2 x 20%]  -- Expand if metrics are normal
Step 3: [v1 x 50%] [v2 x 50%]  -- Further expansion
Step 4: [v2 x 100%]             -- Full rollout

Per-stage validation criteria:

Automatic rollback conditions:

• Error rate > 1% (2x normal)
• p99 latency > 2 seconds (50% increase from normal)
• Business metric anomaly (conversion rate, revenue, etc.)

4. A/B Testing (Feature Experiment)

• Traffic splitting based on user segments
• Integrated with Feature Flag systems
• Decide after achieving statistical significance

5. Shadow (Mirroring)

• Replicate production traffic to new version (responses discarded)
• Used only for performance, error, and compatibility validation
• Zero user impact

Health Check Design

Three-Level Health Checks

Health Check Response Structure

{
  "status": "healthy",
  "version": "2.1.0",
  "uptime": 86400,
  "checks": {
    "database": { "status": "healthy", "latency": "2ms" },
    "redis": { "status": "healthy", "latency": "1ms" },
    "external_api": { "status": "degraded", "latency": "500ms" }
  }
}

Kubernetes Probe Configuration

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 10
  failureThreshold: 3

readinessProbe:
  httpGet:
    path: /readyz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  failureThreshold: 3

Rollback Procedures

Automatic Rollback Triggers

Rollback Procedure

1. Trigger detected -> Auto-alert (Slack/PagerDuty)
2. Immediate switch to previous version
   - Blue-Green: Switch load balancer
   - Canary: Set canary traffic to 0%
   - Rolling: kubectl rollout undo
3. Root Cause Analysis (RCA)
4. Fix and redeploy

DORA Metrics

4 Key Metrics

Measurement Automation

Deployment frequency = Production deployment event count / period
Lead time = Production deploy time - First commit time
Change failure rate = Rollback deployments / Total deployments x 100
Recovery time = Incident resolution time - Incident detection time

Branch Strategy and Deployment Mapping

Per-Environment Auto-Deployment Rules

feature/* -> PR -> preview environment (ephemeral)
main       -> auto -> staging (automated testing)
main + tag -> manual approval -> production
hotfix/*   -> emergency -> production (simplified approval)