Quest 58 - Deployment Pipeline Designer

Quest 58: Deployment Pipeline Designer

medium 25-30 minutes

---

🎯 Learning Objectives

• ✅ How to design a deployment pipeline with at least 5 stages
• ✅ Why gate criteria at each stage prevent broken code from reaching production
• ✅ How environment progression (dev → staging → prod) catches issues early
• ✅ The importance of rollback strategy and monitoring integration

---

📖 Concept: Deployment Pipeline Architecture

A deployment pipeline is a series of automated gates that every code change must pass through before reaching production. Think of it like a martial arts belt progression — you don’t skip from white to black belt. Each stage proves you’re ready for the next one.

The key engineering habit is: pipeline as gatekeeper. Every change must pass through automated checks before reaching production. No exceptions, no shortcuts. The pipeline is the team’s shared quality contract.

---

⚙️ How It Works

The 5+ Stage Pipeline

Code Commit
    ↓
[Stage 1: Build] → Compile, bundle, create artifacts
    ↓ Gate: Build succeeds, no compilation errors
[Stage 2: Test] → Unit tests, integration tests
    ↓ Gate: All tests pass, coverage ≥ threshold
[Stage 3: Security Scan] → SAST, dependency audit, secret scanning
    ↓ Gate: No critical/high vulnerabilities
[Stage 4: Staging Deploy] → Deploy to staging environment
    ↓ Gate: Smoke tests pass, health checks green
[Stage 5: Production Deploy] → Canary/rolling/blue-green deploy
    ↓ Gate: Error rate < threshold, latency within bounds
[Stage 6: Post-Deploy Monitor] → Watch metrics for 15-30 min
    ↓ Gate: No anomaly alerts
✅ Live

Why Each Stage Matters

Stage	Catches	Cost of skipping
Build	Syntax errors, missing deps	Broken artifact reaches tests
Test	Logic bugs, regressions	Users find the bugs
Security	Vulnerabilities, secrets	Data breach, compliance violation
Staging	Environment-specific issues	“Works on my machine” in prod
Production	Runtime errors, performance	Outage, data loss
Monitoring	Latent issues	Slow degradation unnoticed

---

💡 Example: Pipeline Design Document

## Pipeline Stages

### 1. Build
- Trigger: git push to main
- Actions: npm ci, npm run build, create Docker image
- Gate: Build succeeds, image created

### 2. Test
- Actions: npm test, npm run test:integration
- Gate: 100% tests pass, coverage ≥ 80%

### 3. Security Scan
- Actions: npm audit, gitleaks scan, Snyk test
- Gate: No critical/high CVEs, no leaked secrets

### 4. Staging Deploy
- Actions: Deploy to staging cluster, run smoke tests
- Gate: Health check passes, smoke tests green

### 5. Production Deploy
- Strategy: Canary (10% → 50% → 100%)
- Gate: Error rate < 1%, p95 latency < 500ms

### 6. Post-Deploy Monitor
- Actions: Watch dashboards for 30 minutes
- Gate: No anomaly alerts triggered

## Rollback Strategy
- Automatic rollback if error rate > 5% during canary
- Manual rollback: revert last deployment, previous version auto-restored
- Database migrations: backward-compatible only, separate rollback scripts

---

⚠️ Common Mistakes

Mistake 1: Skipping stages

“Let’s just deploy straight to prod to save time” → Each skipped stage is a bug that reaches users. The time you save is dwarfed by the time you spend on incident response.

Mistake 2: No gate criteria

“The pipeline runs but doesn’t block on failure” → A pipeline that doesn’t block is just a suggestion. Define clear pass/fail criteria for each stage.

Mistake 3: Missing rollback strategy

“We’ll figure out how to roll back if something goes wrong” → By the time something goes wrong, you need a plan NOW — not a plan you’re writing while your service is down.

Mistake 4: No monitoring integration

“Deploy and pray” → Post-deploy monitoring catches issues that automated tests miss: memory leaks, latency spikes, error rate increases.

---

📝 Knowledge Check

📝 Knowledge Check

Q1:What is a 'gate' in a deployment pipeline?

A physical barrier that blocks developers from the server roomAn automated check that must pass before code advances to the next stageA security firewall between environmentsA manual approval step required for every deploy

Q2:Why is a rollback strategy essential before deploying to production?

It makes deployments fasterBy the time something goes wrong, you need a plan NOW — not one you're writing during an outageIt's required by law in all countriesRollback strategies only apply to database migrations

Q3:What is environment progression in a deployment pipeline?

Deploying to all environments simultaneouslyCode moves through dev → staging → production, each stage catching different issuesUsing different programming languages in each environmentRotating encryption keys across environments

---

🏋️ Quest: Deployment Pipeline Designer

Now it’s time to practice! Design a deployment pipeline architecture with at least 5 stages.

1. Download the starter files:

   npx bluebeltdojo download quest-58-deploy-pipeline
   cd quest-58-deploy-pipeline

2. Open problem.js in your editor — it describes the pipeline requirements

3. Write deploy-pipeline.md covering: pipeline stages (5+), gate criteria, rollback strategy, environment progression, and monitoring integration

4. Make sure each stage has clear pass/fail criteria — a pipeline without gates is just a suggestion

5. Verify the design meets all requirements described in problem.js

6. Verify your solution:

   node test.js

7. When ready, submit your solution:

   npx bluebeltdojo submit

💡 Tip: Think about what happens when each stage fails. Who gets notified? Does the pipeline stop? What’s the rollback path? A good pipeline design answers these questions for every stage.

---

คำใบ้

• อ่าน instructions ใน problem.js อย่างละเอียด — ต้องมี pipeline stages อย่างน้อย 5 stages
• ทุก stage ต้องมี gate criteria ที่ชัดเจน (pass/fail)
• ต้องมี rollback strategy — คิดว่าถ้า production พังจะทำยังไง
• ต้องมี environment progression: dev → staging → prod
• ถ้าติดขัด ลองอ่าน “Common Mistakes” อีกครั้ง — อย่าดู solution โดยตรง