Continuous Deployment Strategies

Getting a new build out doesn't have to mean "stop the old version, start the new one" (and the downtime that implies). Different deployment strategies trade off complexity for safety and zero-downtime releases.

Rolling deployment

Replace old instances/Pods with new ones gradually, a few at a time, as covered in the Kubernetes course's Deployments lesson, this is the default behavior for a Kubernetes Deployment. At any moment, some traffic hits the old version and some hits the new one.

Blue-green deployment

Run two full, identical environments, blue (currently live) and green (the new version), deploy entirely to green, test it for real, then switch all traffic over atomically:

Before:  Router → Blue (v1.4)     Green (v1.5, idle)
Switch:  Router → Blue (v1.4, idle)     Green (v1.5)

If something's wrong with green, you switch traffic straight back to blue, instant rollback, no redeploying anything. The cost: you need double the infrastructure running during the switch.

Canary deployment

Send a small percentage of real traffic (say 5%) to the new version, watch error rates and latency, then gradually increase that percentage if everything looks healthy:

5% of traffic  → v1.5 (canary)
95% of traffic → v1.4 (stable)

This catches problems that only show up under real production traffic and load, while limiting the blast radius to a small slice of users if something's wrong.

Feature flags: decoupling deploy from release

A feature flag wraps new code in a runtime toggle, so the code can be deployed to production while still being turned off for real users:

if (featureFlags.isEnabled('new-checkout')) {
  return renderNewCheckout();
}
return renderOldCheckout();

This separates two things that rolling/blue-green/canary strategies bundle together: deploying code (getting it running in production) and releasing a feature (turning it on for users). You can deploy on Tuesday and flip the flag on Friday, no redeploy needed, and instantly turn it back off if something's wrong.