36 / 48 · 16 CI/CD Pipelines · Deployment Strategies← prev⊞ allnext →☰ Read as one page
6.2Blue-Green Deployment
How It Works
Two identical environments exist: blue (current production) and green (new version). The new version is deployed to green. Once validated, traffic switches from blue to green. If anything goes wrong, switch back instantly.
Load Balancer
/ \
Blue (v2.3) Green (v2.4)
[current] [new, being tested]
↑
Run full test suite here
before switching traffic
Where Tests Run
- Before the switch: Run your full browser test suite, integration tests, and performance smoke tests against the green environment
- After the switch: Run smoke tests against production to verify the switch was clean
- Rollback trigger: If post-switch smoke tests fail, switch back to blue immediately
# Example: Blue-green deployment with testing gates
deploy-to-green:
runs-on: ubuntu-latest
steps:
- run: ./deploy.sh green
test-green:
needs: deploy-to-green
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npx playwright test --project=regression
env:
BASE_URL: https://green.example.com
switch-traffic:
needs: test-green
runs-on: ubuntu-latest
steps:
- run: ./switch-traffic.sh blue-to-green
smoke-production:
needs: switch-traffic
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npx playwright test --project=smoke
env:
BASE_URL: https://production.example.com
Risk Level: Low
Instant rollback by switching traffic back to blue. The full test suite runs against the new version before any real users see it.
QA Implications
- You need a complete, reliable test suite that can run against an isolated environment
- Tests must be environment-agnostic (configurable via
BASE_URL) - Test data in the green environment must match production-like conditions
- The test suite must finish in a reasonable time (blocking deployment for 2 hours is unacceptable)