Deployment Strategies Theory

Introduction

Deployment strategies determine how new versions of your application are released to users. The right strategy depends on your requirements for risk, availability, and rollback capability.

---

Blue-Green Deployment

How it works

Blue-Green deployment maintains two identical environments: one active (blue) and one idle (green).

Process

1. Deploy new version to the idle environment (green)
2. Run tests on the idle environment
3. Switch traffic from blue to green at the load balancer level
4. Monitor for issues
5. Keep both environments available for quick rollback

When to use Blue-Green

Use case	Why	Typical wait time
Zero-downtime updates	Traffic switch is instantaneous	Near-instant
Quick rollback needed	Can switch back immediately	Immediate
Complex database migrations	Old version still works during migration	Variable
Testing in production-like environment	Green mirrors production exactly	Hours to deploy
Compliance/maintenance windows	Can prepare ahead of time	Hours

Pros and Cons

Pros:

• Near-zero downtime
• Instant rollback possible
• Full isolation between versions
• Can test full production environment before switching
• Database schema can be backwards compatible

Cons:

• Requires double infrastructure (2x cost)
• Database migration complexity (must handle both versions)
• Data synchronization challenges between environments
• Testing must be thorough before switching
• Not suitable for frequent deployments

---

Canary Deployment

How it works

Canary deployment gradually rolls out the new version to a small subset of users first, then progressively increases traffic.

Process

1. Deploy new version alongside old version
2. Route small percentage of traffic (e.g., 1-5%) to the new version
3. Monitor key metrics (error rates, latency, etc.)
4. If metrics look good, gradually increase traffic (5% → 20% → 50% → 100%)
5. If issues detected, immediately stop the canary and rollback

Typical Canary Phases

Phase	Traffic %	Duration	Goal
Initial	1-5%	15-30 min	Verify basic functionality
Extended	10-20%	1-2 hours	Verify with more user diversity
Major	50%	1-4 hours	Half production load
Complete	100%	Full rollout	Everyone on new version

When to use Canary

Use case	Why
High-traffic applications	Risk is distributed across time
Want gradual feedback	Can see real user behavior
Need to verify with production data	Uses actual production database
Want to minimize blast radius	Issues affect only small user subset
A/B testing features	Can compare metrics between versions

Pros and Cons

Pros:

• Gradual rollout limits blast radius
• Real-world testing with actual users
• Can measure impact on metrics
• No need for duplicate infrastructure
• Can roll back at any point

Cons:

• Longer deployment window
• More complex configuration
• Need feature flags or routing infrastructure
• Traffic split adds complexity
• Can be hard to reproduce issues with partial traffic

---

Rolling Deployment

How it works

Rolling deployment updates instances one at a time (or in batches) while the application continues serving requests.

Process

1. Divide your instances into batches
2. Update one batch at a time
3. Wait for health checks to pass
4. Update next batch
5. Repeat until all batches are updated

When to use Rolling Deployment

Use case	Why
Continuous deployment	Can update frequently
Limited infrastructure	No need for duplicate systems
High availability needed	Always have some instances running
Gradual failure detection	Issues caught early in rollout
Cost-sensitive deployments	No extra infrastructure required

Pros and Cons

Pros:

• No duplicate infrastructure needed
• Can handle large numbers of instances
• Gradual rollout with health checks
• Works well with auto-scaling
• Simpler than canary/blue-green

Cons:

• Deployment takes longer than blue-green
• Rolling back affects all instances
• Can have version skew during deployment
• Some users may see partial updates
• Requires health check infrastructure

---

A/B Testing

How it works

A/B testing deploys two different versions and routes users to each version for comparison.

When to use A/B Testing

Use case	Why
Feature comparison	Test which version users prefer
Performance optimization	Compare latency/cost metrics
Conversion optimization	Test UI changes impact
Pricing experiments	Test different pricing models
Algorithm comparison	Compare ML model versions

---

Feature Flags (Feature Toggles)

How it works

Feature flags allow you to enable/disable features without deploying new code.

Types of Feature Flags

Example: Release Flag Implementation

// Feature flag configuration
const featureFlags = {
  recommendation: {
    enabled: true,
    variants: {
      old: { weight: 0.5, name: 'Collaborative Filtering' },
      new: { weight: 0.5, name: 'Deep Learning' }
    }
  }
};

// Select user variant based on user ID
function getUserVariant(userId: string, feature: string): string {
  const flag = featureFlags[feature];
  if (!flag.enabled) return Object.keys(flag.variants)[0];
  
  // Consistent hashing ensures same user always gets same variant
  const hash = hashCode(userId);
  const total = Object.values(flag.variants).reduce((sum, v) => sum + v.weight, 0);
  let cumulative = 0;
  
  for (const [variant, config] of Object.entries(flag.variants)) {
    cumulative += config.weight;
    if (hash % 100 < cumulative) return variant;
  }
  
  return Object.keys(flag.variants)[0];
}

// Usage in application
function getRecommendations(userId: string) {
  const variant = getUserVariant(userId, 'recommendation');
  
  if (variant === 'old') {
    return collaborativeFilteringRecommendations(userId);
  } else {
    return deepLearningRecommendations(userId);
  }
}

When to use Feature Flags

Flag Type	When to use	Typical value	Duration
Kill switch	Emergency disable	false	Temporary
Gradual rollout	Safe deployment	5% → 20% → 50% → 100%	Days
A/B test	Comparison experiment	50%	Weeks
Permission	Access control	true/false	Permanent
Maintenance	Scheduled updates	false	Hours

---

Comparison Summary

Deployment Time and Risk

When to Use Each Strategy

Scenario	Best Strategy	Alternative
Zero-downtime required	Blue-Green	Canary
Need instant rollback	Blue-Green	None
High availability needed	Rolling	Blue-Green
Gradual risk mitigation	Canary	Rolling
Comparing two versions	A/B Testing	Canary
Cost-sensitive deployment	Rolling	None
Frequent deployments	Rolling	Canary
Complex migrations	Blue-Green	Canary

---

Hybrid Approaches

Blue-Green + Feature Flags

Combine blue-green with feature flags for maximum flexibility:

Canary + Feature Flags

Canary deployments often use feature flags to control traffic routing:

// Canary deployment with feature flag
async function canaryDeploy(newVersion: string) {
  // Deploy to canary environment
  await deployToCanary(newVersion);
  
  // Enable feature flag with 1% traffic
  await featureFlags.setRollout('new-version', 1);
  
  // Gradually increase over time
  await sleep(30 * 60 * 1000); // 30 minutes
  await featureFlags.setRollout('new-version', 5);
  
  await sleep(60 * 60 * 1000); // 1 hour
  await featureFlags.setRollout('new-version', 20);
  
  await sleep(4 * 60 * 60 * 1000); // 4 hours
  await featureFlags.setRollout('new-version', 100);
}

---

Summary

Strategy	Downtime	Rollback Speed	Infrastructure	Complexity	Best For
Blue-Green	Near-zero	Instant	2x	Medium	Zero-downtime, quick rollback
Canary	None	Fast	Same	High	Risk mitigation, gradual rollout
Rolling	None	Moderate	Same	Low	Cost-sensitive, continuous deployment
A/B Testing	None	N/A	Same	Medium	Feature comparison, experimentation
Feature Flags	None	Instant	None	Low	Emergency controls, gradual features

Rule of thumb: Use feature flags with any deployment strategy to add flexibility and control.

---

Further Reading

• Launchdarkly Deployment Strategies
• The Twelve-Factor App