█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/DevOps and Infrastructure/CI/CD Pipelines/Deploy Strategies
35 minAdvanced

Deploy Strategies

After this lesson, you will be able to: Compare rollback, canary, and blue/green deployment strategies and pick the right one for your team.

Deploying isn't enough; deploying SAFELY is. This lesson covers the three deploy patterns mature teams use.

Prerequisites:Security Scanning in CI

Rollback: the minimum bar

Every deploy needs a one-command rollback. Web on Vercel / Netlify: built-in via the dashboard or `vercel rollback`. Kubernetes: `kubectl rollout undo deployment/myapp` or `helm rollback`. Docker on VPS: keep the previous image tag pinned; redeploy with old SHA. Practice the rollback during a quiet day. Knowing the muscle memory is half the value.

Blue/green: two full environments

Two complete production stacks: blue (current) and green (new). Deploy to green; smoke test; switch the load balancer / DNS / Ingress to point at green. Blue still runs in case you need to roll back instantly. Trade-off: doubles infrastructure cost during the switch. Best for: critical systems, low-frequency deploys, big risky changes.

Canary: gradual rollout to a subset

Send 1% of traffic to the new version; watch metrics; if healthy, ramp to 10%, 50%, 100%. Stops bad deploys early, 99% of users see the old (good) version while the 1% catches the bug. Requires: traffic-shifting infrastructure (Ingress with weighted routes, Service Mesh, or a CDN that splits). Best for: high-frequency deploys, large user bases where 1% is meaningful traffic.

Canary with K8s + ingress-nginx

ingress-nginx supports canary annotations natively.

sql
# canary-deployment.yaml: deploy v2 as a separate Deployment
apiVersion: apps/v1
kind: Deployment
metadata: { name: myapp-canary }
spec:
replicas: 1 # keep small until ramping
selector: { matchLabels: { app: myapp, version: v2 } }
template:
metadata: { labels: { app: myapp, version: v2 } }
spec:
containers: [{ name: web, image: myapp:v2 }]
---
apiVersion: v1
kind: Service
metadata: { name: myapp-canary }
spec:
selector: { app: myapp, version: v2 }
ports: [{ port: 80, targetPort: 3000 }]
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: myapp-canary
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10" # 10% of traffic
spec:
ingressClassName: nginx
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service: { name: myapp-canary, port: { number: 80 } }

💡 Feature flags: the simpler 'canary'

Instead of two deploys, deploy the new code BEHIND A FLAG that defaults off. Flip the flag for 1% of users via your flag service (LaunchDarkly, GrowthBook, your own DB). Bug? Flip the flag off. No rollback, no redeploy. Often replaces canary deploys entirely; cheaper and faster than infrastructure splitting.

Common mistakes only experienced engineers avoid

No rollback practice. The first time you try is during an outage; you forget the command. Canary without observability. Without metrics, the canary is a coin flip. Blue/green without DB migration discipline. The green env reads/writes the SAME DB; backwards-incompatible migrations break blue. Treating canary % as 'good enough' without time. 1% for 1 minute catches nothing; 1% for 1 hour catches real issues. Skipping feature flags. Most rollback scenarios are flag flips waiting to happen.

Quick Check

Which strategy lets you stop a bad deploy mid-rollout WITHOUT redeploying?

Pick the one with the fastest abort path.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Security Scanning in CI
Back to CI/CD Pipelines
ArgoCD and GitOps→