Greetings, brave adventurer! You have learned to build and to test. Now comes the most dangerous moment in all of software: the crossing into production, where real users live and real money flows. This quest, Deployment Pipelines, teaches you to make that crossing not with held breath and crossed fingers, but with a disciplined, reversible, automated procession.

Whether you have only ever dragged files onto a server or you already deploy on a schedule, this adventure forges the strategies that let great teams ship dozens of times a day without fear: environment promotion, blue-green and canary releases, human approval gates, and the all-important art of the rollback.

📖 The Legend Behind This Quest

Long ago, “release day” was a feared festival. The whole guild gathered, deployed everything at once, and prayed. When it broke - and it always broke - there was no way back but a frantic, hours-long scramble to rebuild the old world from memory.

The masters of delivery rejected this terror. They declared that every deployment must be small, observed, and reversible. They built procession routes - dev to staging to production - and invented techniques to swap the kingdom’s banner without the citizens ever noticing. Above all, they made the retreat as fast as the advance. Master this and a bad deploy becomes a minor inconvenience, not a catastrophe.

🎯 Quest Objectives

By the time you complete this journey, you will have mastered:

Primary Objectives (Required for Quest Completion)

• Environment Promotion - Move a build through dev, staging, and production stages
• Deployment Strategies - Compare recreate, rolling, blue-green, and canary releases
• Approval Gates - Require a human sign-off before a production deploy
• Rollbacks - Design an automatic and a manual path back to the last good release

Secondary Objectives (Bonus Achievements)

• Progressive Delivery - Shift traffic gradually and watch metrics before going to 100%
• Deployment Health Checks - Verify a new version is healthy before sending it traffic
• Immutable Releases - Deploy a versioned artifact, never a mutated server

Mastery Indicators

You’ll know you’ve truly mastered this quest when you can:

• Choose a deployment strategy for a given risk profile
• Explain why blue-green makes rollback instant
• Define a metric that automatically aborts a canary
• Promote the same artifact from staging to production

🗺️ Quest Prerequisites

📋 Knowledge Requirements

• Understanding of CI stages and gated tests (see Testing Integration)
• Familiarity with Git, branches, and pull requests
• A mental model of how a web service runs and receives traffic

🛠️ System Requirements

• Modern operating system (Windows 10+, macOS 10.14+, or Linux)
• Git installed and a free GitHub account
• A text editor or IDE (VS Code recommended)

🧠 Skill Level Indicators

This 🔴 Hard quest expects:

• You already have a CI pipeline that builds and tests
• You are ready to reason about production risk
• Ready for 90-120 minutes of focused learning

🌍 Choose Your Adventure Platform

Deployment targets vary, but the pipeline patterns are universal. Each path sets up a deploy target you can promote into. The GitHub Actions environment model in Chapter 3 works on every platform.

🍎 macOS Kingdom Path

🪟 Windows Empire Path

🐧 Linux Territory Path

☁️ Cloud Realms Path

🧙‍♂️ Chapter 1: Environments and Promotion

A change should never leap straight from a laptop to production. It travels a road of increasingly production-like environments, proving itself at each stop.

⚔️ Skills You’ll Forge in This Chapter

• The role of dev, staging, and production
• “Build once, promote the same artifact”
• Why promotion beats rebuilding

🏗️ The Promotion Road

  ┌──────┐     ┌──────────┐     ┌────────────┐
  │ dev  │ ──► │ staging  │ ──► │ production │
  └──────┘     └──────────┘     └────────────┘
  fast iter.   prod-like,        real users
  loose data   integration,      real money
               smoke tests       gated by approval

The single most important rule: build the artifact once, then promote that exact artifact through each environment. If you rebuild between staging and production, the binary you tested is not the binary you ship, and “works in staging” guarantees nothing. Promotion changes configuration (which database, which API keys) but never the code artifact.

🔍 Knowledge Check: Promotion

• Why must production be as “prod-like” as possible before it?
• What changes between environments - the artifact or its configuration?
• Why is rebuilding between staging and production a trap?

⚡ Quick Wins and Checkpoints

• Drew the road: You sketched dev → staging → production
• Stated the rule: “Build once, promote the same artifact”

🧙‍♂️ Chapter 2: Deployment Strategies - Swapping the Banner

How you replace a running version matters as much as what you replace it with. Each strategy trades speed, cost, and risk differently.

⚔️ Skills You’ll Forge in This Chapter

• Recreate, rolling, blue-green, and canary deployments
• The rollback story for each
• Choosing a strategy by risk tolerance

🏗️ The Four Strategies

Blue-green keeps the old version fully running until the new one is proven, so rollback is a single, instant traffic switch. Canary is the most cautious: a small fraction of users hit the new version while you watch error rates and latency; only a healthy canary is promoted to full traffic.

Canary in action:
  t0:  100% stable        0% canary
  t1:   95% stable        5% canary   ← watch error rate & latency
  t2:   75% stable       25% canary   ← still healthy? keep ramping
  t3:    0% stable      100% canary   ← promotion complete
  abort: route 100% back to stable the instant a metric breaches its threshold

🔍 Knowledge Check: Strategies

• Why is rollback instant with blue-green but slow with recreate?
• What does a canary watch before ramping traffic up?
• Which strategy fits a high-traffic payment service, and why?

🧙‍♂️ Chapter 3: Approval Gates and Rollbacks

The final crossing into production deserves a guard - sometimes a machine, sometimes a human - and an always-ready retreat.

⚔️ Skills You’ll Forge in This Chapter

• GitHub Actions environments with required reviewers
• Automatic rollback triggers from health checks
• The manual rollback escape hatch

🏗️ A Promotion Pipeline with an Approval Gate

GitHub Actions environments can require a human reviewer and hold secrets. A job targeting a protected environment pauses until an approver clicks “Approve.”

name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy-staging:
    runs-on: ubuntu-latest
    environment: staging          # auto-deploys; no reviewer required
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy.sh staging
      - run: ./scripts/smoke-test.sh staging   # health-check the new version

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production       # protected: requires manual approval
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/deploy.sh production
      - name: Verify health, roll back on failure
        run: |
          if ! ./scripts/health-check.sh production; then
            echo "Health check failed — rolling back"
            ./scripts/rollback.sh production
            exit 1
          fi

To make the production job wait for a human, open the repository’s Settings → Environments → production and add Required reviewers. The deployment then halts until an authorized person approves it.

🏗️ The Rollback Discipline

A rollback returns production to the last known-good release. Two paths must always exist:

# Automatic: triggered by a failing health check (as in the workflow above)
./scripts/health-check.sh production || ./scripts/rollback.sh production

# Manual: a human pulls the cord when monitoring looks wrong
gh workflow run rollback.yml -f environment=production -f to_version=v1.4.2

The cardinal rule: a deploy you cannot undo is not a deploy, it’s a gamble. Always know how to get back to the previous version before you push the new one out. Versioned, immutable artifacts make rollback as simple as re-pointing at an older tag.

🔍 Knowledge Check: Approvals and Rollbacks

• How do GitHub Actions environments pause a deploy for a human?
• What should a failing post-deploy health check trigger?
• Why must a manual rollback path exist even with automatic rollback?

🎮 Mastery Challenges

🟢 Novice Challenge: Pick the Strategy

Objective: Match a deployment strategy to three scenarios.

Requirements:

• A hobby blog with occasional updates → choose a strategy
• A stateless API behind a load balancer → choose a strategy
• A payment service at peak traffic → choose a strategy

Validation: You can justify each choice by downtime and rollback speed.

🟡 Intermediate Challenge: Gated Promotion Pipeline

Objective: Build the staging → production workflow from Chapter 3.

Requirements:

• deploy-staging runs automatically with a smoke test
• deploy-production targets a protected environment with a required reviewer
• The same artifact is promoted, not rebuilt

Validation: Production waits for approval; staging deploys on its own.

🔴 Advanced Challenge: Automated Rollback

Objective: Add a health check that rolls back a bad production deploy.

Requirements:

• A post-deploy health check that can fail the job
• An automatic rollback step on failure
• A documented manual rollback command as a backup

Validation: A deliberately broken deploy triggers an automatic rollback to the prior version.

🏆 Quest Rewards & Achievements

🎖️ Badges Earned:

• 🏆 Master of the Release Gate - You promoted code safely to production
• 🔄 Keeper of the Rollback - You designed a safe undo for every deploy

🛠️ Skills Unlocked:

• Progressive Delivery - Roll out gradually and observe before committing
• Rollback Strategy - Make every deployment reversible

🔓 Unlocked Quests:

• Environment Management - Keep dev, staging, and prod in parity
• Secrets Management - Inject the right credentials per environment

📊 Progression Points: +60 XP

🗺️ Next Steps in Your Journey

Continue the Main Story:

• 🎯 Environment Management - Master parity and per-env config

Explore Side Adventures:

• ⚔️ Secrets Management - Credentials without leaks
• ⚔️ Artifact Management - The immutable thing you promote

Character Class Recommendations

💻 Software Developer: Continue to Environment Management
🏗️ System Engineer: Explore Secrets Management
🛡️ Security Specialist: Check out Secrets Management

📚 Resources

Official Documentation

• GitHub Actions: Using environments for deployment - Protected environments and reviewers
• Kubernetes: Deployment strategies - Rolling updates and rollbacks
• Argo Rollouts - Canary and blue-green for Kubernetes

Community Resources

• Martin Fowler: Blue-Green Deployment - The canonical write-up
• Martin Fowler: Canary Release - Progressive delivery explained
• AWS: Deployment strategies - Cloud-native patterns

Learning Materials

• Accelerate / DORA metrics - The research linking safe deploys to performance
• Continuous Delivery (Humble & Farley) - The foundational book

🤝 Quest Completion Checklist

• ✅ Completed all primary objectives
• ✅ Built a gated promotion pipeline with an approval
• ✅ Answered all knowledge check questions
• ✅ Completed at least one mastery challenge
• ✅ Explored the resource library
• ✅ Identified your next quest in the journey

🕸️ Knowledge Graph

Structured wiki-links connect this quest to the IT-Journey knowledge graph. Open the Obsidian Graph View to explore connections.

Level hub: [[Level 0101 - CI/CD & DevOps]] Overworld: [[🏰 Overworld - Master Quest Map]] Requires: [[CI/CD Fundamentals: Continuous Integration and Continuous Deployment Essentials]] · [[Testing Integration: Automated Quality Assurance in CI/CD Pipelines]] Unlocks: [[Environment Management: Dev, Staging, and Production Configuration]] · [[Secrets Management: Secure Configuration and Credential Handling]] Obsidian docs: [[Obsidian Knowledge Graph and Wiki Links]]