practice · releases

Release gate

A release gate is a state, not a meeting. The change either is or is not safe to flip the flag — and the team can answer in one line. If you need a meeting to find out, the gate has already failed.

TL;DR

The release gate is three signals the team reads together: build green, QA paragraph signed, observability hooks live. The cycle's flag does not flip until all three are green. The gate is a state visible on a dashboard, not a meeting. The TL is accountable; QA writes the safe to ship paragraph; the PO holds the prediction's check date and confirms the rollout plan.

What it is

The release gate is the moment between the build has merged and the change is in front of named persons. It is described in As We Build · Release Gate. Its discipline is that the gate is legible at a glance — anyone in the team can read whether the cycle is shippable in five seconds.

Distinguish from

Deploy — pushing the build to production; technical act. Sign-off meeting — the corrupted shape of the gate; if you need one, the artefacts are unreadable. Ship-it — what happens after the gate passes. See Confusable with at the foot.

Why it matters

Without a release gate:

• The cycle ships at random. Each release is a one-off negotiation between engineering and QA.
• Risk is invisible. Is this safe? gets answered by feel, not by readable signals.
• No-surprises rule breaks both ways. The client learns of a release at the same time the team does; the on-call learns when the page fires.
• The first 48h is unprepared. Observability arrives after the change; nobody is watching the right dashboard.

The release gate is the corpus's discipline against the release happening by accident.

How to do it

Step 1 — Define the three signals before the cycle starts

The signals live in the Technical Design Brief. Each signal is one line; each line is binary.

Release gate signals (TDB · cycle 2026-Q2):
  1. Build green:        all pre-merge stages pass, including
                         performance budget for grader.queue.
  2. QA paragraph:       signed "safe to ship" or "safe under
                         flag" with named risks.
  3. Observability live: queue.opened and queue.graded events
                         flowing to dashboard; alerts wired.

Three signals is the corpus default. More than four is hard to read. Less than three usually misses observability.

Step 2 — Make the gate visible

Each signal is on the team's release dashboard (or pinned in the team's chat). The gate's state is derived, not asserted. Build green is derived from CI. QA paragraph is derived from the signed PR. Observability live is derived from event volume in the last 15 minutes.

Gate state: 2 / 3
  ✅ Build green
  ⚠ QA paragraph: pending (Maya at amigos)
  ✅ Observability live

When the gate is two-of-three, the team can name what is missing without a meeting. That is the discipline.

Step 3 — QA writes the paragraph, not the team

QA: Safe to ship under flag.
Risks named:
  - Hebrew normalisation: handles the supported unicode set;
    fallback works in QA staging. Production has not been
    tested against the legacy import set; if those rows
    appear in flag-enabled grader queues, names will render
    with fallback character. Mitigation: monitor
    name.display.fallback rate in first 48h.

Maya (QA) · 2026-05-23

If the QA cannot write three sentences with a named risk, the gate is not green. Vague paragraphs are the warning sign.

Step 4 — TL accountable; PO confirms the prediction's check is wired

The TL's name is on the gate. They read the three signals and call shippable or not. The PO confirms: the prediction's check date is in the calendar; the dashboard panel the check will read is live.

Step 5 — Flip the flag

The flag flips by the team, not by the deploy. Deploy without flag-flip is the change in the building, not in front of the named person. The flip is the chain's release act.

Step 6 — Hand off to the first 48h watch

The gate is the door; the watch is the hallway. The same dashboard the gate read becomes the dashboard the watch reads.

Evidence

Across our cycles, releases that survived the first 48h cleanly shared three properties.

1. The gate was three signals, not five. Cycles with 5+ gate signals had release-blocker friction 2× higher; teams started arguing about which signal mattered most rather than acting on the gate.
2. The QA paragraph named a specific risk, not a feeling. Releases whose QA paragraph included a specific mitigation in the first 48h watch surfaced fewer surprise incidents.
3. The gate was visible without a meeting. Cycles where someone had to ask is this safe? in chat ran 1.5× longer to flag-flip.

Anti-patterns

Pattern	What it looks like	Where to fix
Gate as a meeting	Weekly release readiness call	Make the state visible. The meeting is a symptom that the artefacts are unreadable.
Five-signal gate	Every concern got added as a signal	Cut to three. Move the rest into pre-merge gates.
QA paragraph is a feeling	"Looks good to me!"	Push back. Name the risk you imagine; name how it would surface.
Deploy without flag-flip	The build is in prod but no person sees the change	The flag is the release; deploy is the precursor
Observability arrives after the gate	Dashboard panels created post-flip	The hook should land with the flag, not after
Gate green but on-call wasn't notified	First the PO finds out, second engineering, last on-call	Re-walk Did We Serve · Ongoing Relationship

Confusable with

This	Not this	Difference
Release gate	Deploy	Gate = state; deploy = act. Deploy happens earlier (usually with the flag off).
Safe to ship	Done	Done = code merged. Safe to ship = the team flips the flag and watches.
Gate signal	Test pass	A signal is a state derived from many things; a test pass is one input.

Further reading

• Canon — As We Build · Release Gate · Feature Flags · Gradual Rollout
• Practice — First 48 hours watch · Writing Technical Design Briefs
• Template — Release brief to client
• Checklist — Release gate · state-not-meeting
• Clinic — A flag that never got cleaned up
• Skill path — QA foundations · Step 7 · Tech Lead foundations · Step 7
• Reference — Area · Release Gate