Deployment Strategies Review: Blue-Green, Canary, Rolling

Releasing software is easy; releasing safely is the craft. The four classic strategies — downtime, blue-green, rolling, and canary — trade off speed, risk, and resource cost. CI's job is to decide and drive the strategy, so the pipeline, not a frantic human in a terminal, performs the release and knows what to do when something looks wrong.

Rolling deployment

A rolling deployment replaces old instances with new ones gradually. It needs no extra capacity, keeps the service live throughout, and is the default on many platforms. Its weakness: during the window, old and new versions serve traffic simultaneously, so a schema or API mismatch in between can break requests. It also gives your pipeline less ability to call the whole change back in one instant.

Blue-green deployment

Blue-green runs two full environments. The live one — say blue — serves all traffic; green hosts the new release. When green passes its checks, you flip the router from blue to green in one atomic cutover, then retire or keep blue as the instant rollback target.

# switch router to the green environment
name: flip
on:
  workflow_dispatch:
jobs:
  switch:
    runs-on: ubuntu-latest
    steps:
      - run: ./scripts/traffic --set green
      - run: curl -fsS https://green.example.com/healthz
      - run: ./scripts/smoke --env green

The atomic cutover plus a preserved blue environment means the previous version is still running and ready, so rolling back is another flip, not a rebuild.

Canary deployment

A canary is a rolling release with a conscience: it routes a small, controlled slice of traffic to the new version while the majority stays on the old one. When that slice demonstrates healthy metrics for a window, the pipeline widens the canary — 5 percent, 25 percent, 50 percent — until all traffic is on the new version.

# step a canary by shifting a weight in the mesh config
kubectl set traffic-weight web-green=(curl -s https://cloud.internal/canary/weight)
kubectl rollout status deploy/web-green

Canary is the most surgical and the most operationally involved, since it requires per-instance traffic shaping. It shines for high-stakes changes where a tiny misbehavior reaching real users early is acceptable in exchange for catching showstoppers before full blast.

What CI should verify before and after each

Every strategy benefits from a shared pre-flight gate and a post-flight check. Before switching traffic, CI should confirm the artifact's health endpoints respond, config is valid, and any migration applied cleanly. After the switch, CI should run smoke checks against the live environment and compare error rates to a baseline. The difference between strategies is mostly about when you run these and how much traffic is at risk when you do.

Matching strategy to risk and cost

There is no single best strategy; there is a good fit per change type.

• Low-risk, high-frequency internal changes: rolling is fine and cheap.
• Core user-facing releases where downtime is unacceptable and rollback must be instant: blue-green.
• Large, risky migrations where you want real traffic feedback before full blast: canary.
• Pinpoint changes to a tiny surface: a targeted canary of seconds can suffice.

The decisive factor is how you detect a bad release. Blue-green and canary only help if your pipeline can tell healthy from broken quickly — which returns you to solid metrics, the topic of a later post in this series. A strategy with no detection is just theater.

Cost and capacity realities

Blue-green roughly doubles your running resource count during the overlap, which is why it is often recommended for short windows or during low traffic. Canary needs the least extra capacity but the most networking plumbing. Treat these as real trade-offs and pick honestly rather than defaulting to the coolest option. Many teams run rolling as the default, reserve blue-green for release night, and use canary only for the riskiest tenants of their service.

Takeaway: choose your strategy by risk and detection ability, and let CI drive it — gate traffic switches, run post-flight smoke checks, and keep rollback one command away. Host your release targets on a Netbay VPS in Lucknow DC01 and spin up the capacity you need in under 60 seconds at netbayhosts.in.