Deployment Strategies, Expressed as Pipeline Stages

In one line

Recreate, rolling, blue-green, and canary are all genuine strategies for how a new version actually replaces the old one — each expressible as concrete pipeline stages, regardless of which platform is running them.

0/4 · 0%

Key ideas

01
This topic covers the SAME four deployment strategies from the original DevOps roadmap's own dedicated section, now from the PIPELINE's point of view specifically — Kubernetes' own course already implemented rolling updates directly (Phase 6.3 of that course); this topic is about how a CI/CD pipeline itself ORCHESTRATES any of these strategies as a sequence of real, concrete stages.
02
RECREATE is the simplest: stop the old version entirely, THEN start the new one — genuine downtime between the two, acceptable only for workloads that can tolerate a brief interruption (an internal batch-processing tool, say), expressed as a pipeline with a stop-old stage strictly before a start-new stage.
03
ROLLING (Kubernetes' own default, that course's Phase 6.3) gradually replaces old instances with new ones — a pipeline orchestrating this outside Kubernetes' own built-in mechanism would need EXPLICIT stages: deploy new instances behind a load balancer, verify their health, gradually shift traffic, then remove the old instances only once the new ones are confirmed healthy.
04
BLUE-GREEN maintains TWO complete, parallel environments ('blue,' currently live, and 'green,' the new version) — the pipeline deploys the new version to the entirely idle 'green' environment, runs real validation against it while it receives zero live traffic, and then SWITCHES a router/load balancer to send all traffic to 'green' in one atomic step — genuinely useful because rollback is just switching the router back to 'blue,' which is still fully running and untouched.
05
CANARY releases the new version to a genuinely SMALL SLICE of real traffic first (Kubernetes' own course, Phase 8.3, showed this exact mechanism via a service mesh's traffic-splitting rules) — a pipeline orchestrating canary explicitly needs an ANALYSIS stage: deploy to the small slice, wait, check real metrics (error rate, latency) against the old version's baseline, and only PROCEED to shift more traffic if those metrics genuinely look healthy, or roll back automatically if they don't.
06
The genuinely important, cross-cutting realization: EVERY one of these strategies can be expressed as ordinary pipeline stages (deploy, verify, shift traffic, cleanup) — the specific mechanism differs (Kubernetes' own rolling-update controller, a load balancer's routing rules, a service mesh's traffic split), but the PIPELINE's job in every case is the same: orchestrate the sequence and decide, based on real verification, whether to proceed or roll back.

Code & diagrams

FourStrategiesCompareddiagram

Four genuinely different answers to the same question: how does new code actually replace old code, safely.

Rendering diagram…

canary-pipeline.ymlmarkdown

A genuine analysis stage — the pipeline itself decides whether to proceed, based on real observed metrics.

stages:
  - deploy-canary
  - analyze-canary
  - promote-or-rollback

deploy-canary:
  stage: deploy-canary
  script:
    - ./deploy.sh canary myapp:$VERSION --traffic-weight=5

analyze-canary:
  stage: analyze-canary
  script:
    - sleep 300    # let real traffic accumulate against the canary
    - ./check-metrics.sh canary --max-error-rate=1% --max-p99-latency=500ms
    # exits non-zero if the canary's real metrics look unhealthy —
    # correctly FAILING this stage if something's genuinely wrong

promote-full:
  stage: promote-or-rollback
  script:
    - ./deploy.sh production myapp:$VERSION --traffic-weight=100
  rules:
    - if: '$CI_JOB_STATUS == "success"'   # only if analyze-canary passed

rollback-canary:
  stage: promote-or-rollback
  script:
    - ./deploy.sh canary myapp:$PREVIOUS_VERSION --traffic-weight=0
  when: on_failure                          # automatically, if analyze-canary failed

Explain it without notes

Why does blue-green's rollback tend to be genuinely faster and safer than a rolling update's rollback?

What real, concrete decision does a pipeline's canary analysis stage need to make, and what should it base that decision on?

Practice

Sketch, as pipeline stages, how you would implement a blue-green deployment for a hypothetical application, including the specific stage where the router/load balancer switch actually happens.

For the canary pipeline example in this topic, explain what should happen if analyze-canary's metrics check genuinely fails, and trace through exactly which job would run as a result.

Trade-offs

↔
Blue-green and canary both provide genuinely strong safety properties, but blue-green requires maintaining TWO full sets of running infrastructure simultaneously (a real, ongoing cost), while canary requires genuine, reliable real-time metrics to actually make its analysis decision correctly — a team without solid monitoring (Topic 6.1's own point, revisited here) can't safely automate canary analysis at all, since the entire strategy depends on trustworthy, fast signal about the canary's real health.

Done when you can

I can describe all four deployment strategies (recreate, rolling, blue-green, canary) and a genuine use case for each.
I can express blue-green or canary as concrete pipeline stages, including where the real decision point is.
I understand why canary's automated analysis stage depends on genuinely trustworthy, real-time monitoring.