Release is not deploy

Two words get used as if they mean the same thing, and almost every deployment problem lives in the gap between them.

Deploy is putting new code on the infrastructure. Release is letting users reach it. Every strategy in this course is a different way of separating those two events, and the strategies get better as the gap between them widens.

A plain rolling update keeps them together: code arrives and traffic follows it, pod by pod, and the first person to find out whether the release was a good idea is a user.

flowchart LR
  subgraph coupled["Coupled — a rolling update"]
    D1["deploy"] --> R1["release"] --> U1["users find the bug"]
  end
  subgraph separated["Separated"]
    D2["deploy"] --> V["verify against production"] --> R2["release, on your terms"]
  end

The four strategies

They answer different questions, so they are no ladder to climb:

• Is this build healthy? Blue-green. Verify the whole new environment, then send everyone at once.
• Is this change good for real users? Canary. Give it 5% of traffic and read the errors.
• Should this specific user see this feature yet? Flags, which have nothing to do with deployment.

Many mature setups use all three, because they operate at different layers: blue-green and canary control which build serves traffic, and flags control which behavior a build shows.

The thing all of them share

Every strategy in this course has the same hard constraint, and it concerns data, not traffic:

Two versions of your code will run against one database at the same time.

In blue-green, both environments point at the same data. In canary, the old and the new share it. Even a rolling update runs old and new pods against one schema. No deployment strategy gives you two versions of your data, and pretending otherwise is where the incidents come from.

That is why the migration discipline from the earlier deployment courses is a prerequisite here: a release strategy you cannot roll back is a slower way of shipping the same outage. Lesson 5 is about that constraint.

What "zero downtime" requires

The phrase gets attached to tooling, but the tooling is the smaller half:

1. A health signal that means something. If /up returns 200 while the app cannot reach the database, every strategy here confidently promotes a broken version.
2. Graceful shutdown. Old instances must finish in-flight requests before stopping (drain_timeout in Kamal, terminationGracePeriodSeconds in Kubernetes).
3. Backward-compatible changes: schema, cache formats, job payloads, session data, anything two versions touch.
4. A rollback you have tried. A rollback path that has never been exercised is only a plan.

Three of those four are properties of your application. Only the second is bought with infrastructure.

What this course covers

1. Release is not deploy (you are here).
2. Blue-green: two environments, one switch.
3. Canary: releasing to a fraction.
4. Feature flags: releasing to a person.
5. The database is the hard part.
6. Deciding, and rolling back.
7. Putting it together: choosing a strategy.

Key takeaways

• Deploy puts code on infrastructure; release lets users reach it. Every strategy here widens the gap between them.
• Blue-green switches whole environments, canary splits traffic, and flags control code paths per user; they solve different problems and compose.
• All of them run two code versions against one database at the same time.
• Zero downtime needs a truthful health check, graceful shutdown, backward-compatible changes, and a rollback you have tested.