GitScrum / Docs
All Best Practices

Deployment Strategies | Blue-Green & Canary

Implement automated deployment pipelines that are reliable and safe. GitScrum supports blue-green, canary releases, and feature flag strategies with rollback.

7 min read

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

StrategyRisk LevelRollback Speed
Blue-greenLowInstant
CanaryLowFast
RollingMediumMedium
All-at-onceHighSlow

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

    Related Solutions