7 min read • Guide 329 of 877
Deployment Automation Strategies
Manual deployments are slow, error-prone, and stressful. Automated deployments are repeatable, fast, and boring—which is exactly what you want. This guide covers strategies for building deployment automation that teams can trust.
Deployment Approaches
| Strategy | Risk Level | Rollback Speed |
|---|---|---|
| Blue-green | Low | Instant |
| Canary | Low | Fast |
| Rolling | Medium | Medium |
| All-at-once | High | Slow |
CI/CD Pipeline
End-to-End Automation
CI/CD PIPELINE STRUCTURE
════════════════════════
STAGES:
─────────────────────────────────────
┌─────────────────────────────────────────────────────────────┐
│ CI/CD PIPELINE │
├─────────────────────────────────────────────────────────────┤
│ Build Test Deploy Deploy Deploy │
│ ───── ──── ────── ────── ────── │
│ Staging Canary Prod │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │Build│───▶│Tests│───▶│Stage│──[OK]─▶│Canary│──▶│ Prod │ │
│ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ │
│ │ │ │ │
│ [Auto] [Auto] [Manual] │
│ or [Auto] │
└─────────────────────────────────────────────────────────────┘
BUILD STAGE:
─────────────────────────────────────
├── Compile/transpile code
├── Install dependencies
├── Generate artifacts
├── Create Docker image
├── Store in registry
└── Versioned, reproducible
TEST STAGE:
─────────────────────────────────────
├── Unit tests
├── Integration tests
├── Security scan
├── Lint and style checks
├── Build verification
└── Quality gates
DEPLOY STAGING:
─────────────────────────────────────
├── Automatic on main merge
├── Full production-like environment
├── Run smoke tests
├── Manual testing possible
└── Gate before production
DEPLOY PRODUCTION:
─────────────────────────────────────
├── Manual approval (optional)
├── Canary first (percentage)
├── Monitor for errors
├── Full rollout if healthy
├── Auto-rollback on failure
└── Zero downtime
Blue-Green Deployment
Instant Rollback Capability
BLUE-GREEN DEPLOYMENT
═════════════════════
CONCEPT:
─────────────────────────────────────
Two identical environments:
├── Blue: Current production
├── Green: New version
├── Only one active at a time
├── Switch is instant
└── Rollback = switch back
FLOW:
─────────────────────────────────────
1. Blue is live (current version)
2. Deploy new version to Green
3. Test Green thoroughly
4. Switch traffic to Green
5. Green is now live
6. Blue becomes staging/backup
7. If problems: switch back to Blue
Before switch:
┌─────────────┐ ┌─────────────┐
│ BLUE │ │ GREEN │
│ v1.4.0 │ │ v1.5.0 │
│ (LIVE) │ │ (testing) │
└──────┬──────┘ └─────────────┘
│
──────▶│ Traffic
After switch:
┌─────────────┐ ┌─────────────┐
│ BLUE │ │ GREEN │
│ v1.4.0 │ │ v1.5.0 │
│ (backup) │ │ (LIVE) │
└─────────────┘ └──────┬──────┘
│
──────▶│ Traffic
BENEFITS:
─────────────────────────────────────
├── Instant rollback (seconds)
├── Zero downtime
├── Full testing before go-live
├── Clear separation
└── Confidence in deployments
CONSIDERATIONS:
─────────────────────────────────────
├── Need 2x infrastructure (temp)
├── Database compatibility
├── Session handling
├── Cache warming
└── Worth the complexity
Canary Releases
Gradual Rollout
CANARY DEPLOYMENT
═════════════════
CONCEPT:
─────────────────────────────────────
Gradual traffic shift:
├── Deploy new version
├── Send small % of traffic
├── Monitor for issues
├── Increase % if healthy
├── Full rollout or rollback
└── Controlled risk
PHASES:
─────────────────────────────────────
Phase 1: 1% traffic (canary)
├── New version gets 1%
├── Monitor errors, latency
├── Compare to baseline
├── 15-30 minutes
└── Quick detection
Phase 2: 10% traffic
├── Increase if Phase 1 good
├── More traffic validates
├── Monitor same metrics
├── 30 minutes
└── Building confidence
Phase 3: 50% traffic
├── Significant rollout
├── Watch carefully
├── Ready to rollback
└── Approaching full
Phase 4: 100% traffic
├── Full rollout
├── Monitor continues
├── Old version retired
└── Deployment complete
AUTOMATION:
─────────────────────────────────────
Automated canary:
stages:
- deploy-canary:
weight: 1%
duration: 15m
- analyze-canary:
check: error_rate < 0.1%
check: latency_p99 < 200ms
on_fail: rollback
- expand-rollout:
weights: [10%, 50%, 100%]
duration_each: 30m
on_fail: rollback
Rollback Strategies
Fast Recovery
ROLLBACK STRATEGIES
═══════════════════
AUTOMATIC ROLLBACK:
─────────────────────────────────────
Trigger rollback on:
├── Error rate > threshold
├── Latency spike
├── Health check failures
├── Memory/CPU issues
├── Smoke test failures
└── No manual intervention needed
Example config:
rollback:
triggers:
- condition: error_rate > 1%
duration: 5m
- condition: p99_latency > 500ms
duration: 10m
- condition: health_check == failing
count: 3
action: revert_to_previous
INSTANT ROLLBACK (Blue-Green):
─────────────────────────────────────
├── Traffic switch
├── Seconds to recover
├── Previous version still running
├── No redeploy needed
└── Best rollback experience
REVERT DEPLOY (Redeploy):
─────────────────────────────────────
├── Deploy previous version
├── Minutes to recover
├── Needs deployment time
├── Works with any strategy
└── Common approach
FEATURE FLAG ROLLBACK:
─────────────────────────────────────
├── Disable feature flag
├── Instant effect
├── No deployment needed
├── Granular control
├── Best for feature issues
└── Separate from deploy rollback
Database Migrations
Safe Schema Changes
DATABASE MIGRATION STRATEGY
═══════════════════════════
PRINCIPLES:
─────────────────────────────────────
├── Always backward compatible
├── Separate from app deploy
├── Rollback script ready
├── Test in staging first
├── Monitor during migration
└── Never break running app
EXPAND-CONTRACT PATTERN:
─────────────────────────────────────
Adding column:
1. Expand: Add new column (nullable)
2. Deploy: App writes to both
3. Migrate: Fill old data
4. Contract: Make required, remove old
Example:
Phase 1 (expand):
ALTER TABLE users ADD COLUMN email_new VARCHAR;
Phase 2 (deploy):
App writes to both email and email_new
Phase 3 (migrate):
UPDATE users SET email_new = email WHERE email_new IS NULL;
Phase 4 (contract):
ALTER TABLE users DROP COLUMN email;
ALTER TABLE users RENAME email_new TO email;
TIMING:
─────────────────────────────────────
1. Run migration (before deploy)
2. Deploy app (uses new + old)
3. Verify success
4. Run cleanup migration (later)
Never run breaking migrations
in same deploy as code changes.
Deployment Notifications
Team Awareness
DEPLOYMENT NOTIFICATIONS
════════════════════════
NOTIFY ON:
─────────────────────────────────────
├── Deployment started
├── Deployment succeeded
├── Deployment failed
├── Rollback triggered
├── Canary status changes
└── Keep team informed
CHANNELS:
─────────────────────────────────────
├── Slack #deployments channel
├── Email for failures
├── PagerDuty for critical failures
├── Dashboard status
└── Multiple channels for redundancy
GOOD NOTIFICATION:
─────────────────────────────────────
✅ Deploy started: app v1.5.0 → staging
by @sarah via GitHub Actions
[View pipeline] [View PR]
✅ Deploy complete: app v1.5.0 → staging
Duration: 3m 24s
All health checks passed
[View logs]
❌ Deploy failed: app v1.5.0 → production
Error: Health check timeout
Auto-rollback initiated
[View logs] [View incident]
GitScrum Deployment
Integration
GITSCRUM DEPLOYMENT FEATURES
════════════════════════════
TASK STATUS ON DEPLOY:
─────────────────────────────────────
├── Task deployed → automatic status update
├── Environment tracking per task
├── "Deployed to staging" label
├── "In production" indicator
└── Visibility of what's where
RELEASE TRACKING:
─────────────────────────────────────
├── Release contains tasks
├── Release deployment status
├── What shipped with this release
├── Changelog generation
├── Complete release picture
└── Stakeholder communication
DEPLOYMENT DASHBOARD:
─────────────────────────────────────
├── Recent deployments
├── What's in each environment
├── Pending items for release
├── Deployment frequency metrics
└── Team visibility
Best Practices
For Deployment Automation
- Automate everything — Repeatability and speed
- Use staged rollout — Canary or blue-green
- Auto-rollback — Fast recovery on failure
- Separate DB migrations — Never same deploy
- Monitor deployments — Know when things break
Anti-Patterns
DEPLOYMENT AUTOMATION MISTAKES:
✗ Manual deployments
✗ All-at-once to production
✗ No rollback plan
✗ DB migration in same deploy
✗ No monitoring during deploy
✗ Deploy Friday afternoon
✗ No staging environment
✗ No deployment notifications