Deployment Strategies

CI/CD Pipelines — Deployment Strategies

CI/CD Pipelines

Chapter 7 · Deployment Strategies

🚦 Deployment Strategies

Chapter 6 produced a traceable, registry-hosted image. This chapter covers how that image actually replaces what's currently running in production — without an outage, and without serving broken code to everyone at once.

The Core Problem

Simply stopping the old version and starting the new one means downtime — unacceptable for most real services. Every strategy below is a different answer to transitioning from old to new code while the service keeps serving traffic.

Rolling Deployment

Replace instances of the old version gradually — a few at a time, waiting for each batch to pass health checks before moving to the next. Simplest strategy, no extra infrastructure needed, but a bug in the new version affects a growing fraction of traffic as the rollout proceeds, and rolling back mid-rollout means dealing with a mix of both versions simultaneously for a while.

🔵🟢 Blue-Green Deployment

Maintain two complete, identical production environments — "blue" currently live, "green" idle. Deploy the new version entirely to green, test it there while blue still serves all real traffic, then switch all traffic to green at once. Rollback is instant: switch back to blue, which was never touched.

The Tradeoff

Requires double the infrastructure — running two full environments simultaneously, at least during the switch window. A genuinely more expensive setup.

The Payoff

Instant, guaranteed-clean rollback — the old environment was never touched at all, unlike rolling deployment's mid-rollout mixed-version state.

🐤 Canary Deployment

Deploy the new version to a small subset of real traffic first — 5%, say — monitor closely, then gradually increase (5% → 25% → 100%) if things look healthy. Directly reusing TypeScript Course 3's canary deployment chapter: the key advantage is limiting the blast radius of a bad deploy to a small fraction of real users before it ever reaches everyone.

A Conceptual Canary Rollout

Deploy new version to 5% of traffic; check health/error metrics for a set period
If healthy, increase to 25%; check again
If still healthy, increase to 100%
If unhealthy at any step, automatically roll back to the previous version immediately

Strategy	Infra Cost	Blast Radius	Rollback Speed
Rolling	Low	Grows as rollout proceeds	Moderate (mixed versions mid-rollback)
Blue-Green	High (double infra)	All-or-nothing at the switch	Instant
Canary	Moderate	Small, controlled	Fast (small fraction affected)

Blast Radius, at a Glance

Rolling

A bad deploy affects an ever-growing slice of traffic as the rollout continues — the longer it runs undetected, the worse it gets.

Canary

A bad deploy is caught while only 5% of traffic is exposed — dramatically limiting real user impact before it ever reaches everyone.

❤️‍🩹 Automatic Rollback on Health-Check Failure

Regardless of strategy, a robust pipeline defines a health check — a GET /health endpoint the new version must respond to correctly — and automatically rolls back to the previous known-good image if that check fails after deployment. This is what makes a deployment genuinely safe, not just automated. And automatic rollback is impossible without a traceable previous-version tag to roll back to — exactly Chapter 6's tagging gotcha, resurfacing here as a hard prerequisite.

💻 Coding Challenges

Challenge 1: Choose a Strategy for a High-Traffic Checkout Flow

An e-commerce site's checkout flow processes real payments and can't tolerate serving a broken version to a large fraction of users, even briefly. Recommend a deployment strategy and justify it using this chapter's table.

Goal: Practice matching a strategy to a genuinely high-stakes blast-radius concern.

→ Solution

Challenge 2: Explain Why Blue-Green's Rollback Is Instant

Explain specifically why blue-green deployment's rollback is faster and cleaner than rolling deployment's, referencing what happens to the "old" environment in each strategy.

Goal: Practice articulating the structural reason behind blue-green's rollback advantage, not just naming it.

→ Solution

Challenge 3: Design a Health Check

Propose what a GET /health endpoint should actually check for a web app backed by a database, beyond simply returning 200 OK unconditionally, and explain why an unconditional 200 would be a weak health check.

Goal: Practice designing a health check that would actually catch a real failure.

→ Solution

⚠️ Gotcha: Reaching for Canary or Blue-Green by Default

An internal, low-traffic admin tool doesn't need canary's gradual-rollout complexity or blue-green's doubled infrastructure cost — a simple rolling deployment (or even a basic redeploy with a health check) is often the right choice for lower-stakes systems. Reaching for the most sophisticated-sounding strategy by default, rather than matching the strategy to the system's actual blast-radius and cost tradeoff, is a familiar overengineering pattern from earlier in this curriculum (GraphQL vs REST, WebSockets vs SSE) — the same judgment call applies here.

🎯 What's Next

With deployment strategies covered, the next chapter formalizes when deployment actually happens and who approves it: Continuous Deployment & Environments — auto-deploy vs manual approval gates, and GitHub Environments with protection rules.