feature flags · rollout and setup

Gradual rollout

Not every release enables the flag for all users at once. A gradual rollout follows a pattern: a pilot group first (often internal team members or a single client), then a percentage ramp (10%, 25%, 50%, 100%), with time at each step to observe metrics and support tickets. The flag platform handles the targeting; the team decides the pace.

The discipline: at each step, check the SLOs and the early analytics events. If the SLO holds and the analytics events match expectations, proceed to the next step. If anything deviates, pause and investigate before continuing. Rolling back from a partial rollout is disabling the flag — seconds, not hours.

How flags are set up

The flag platform — whatever tool the team uses — needs four things to serve the chain well:

• Runtime toggles — flags can be enabled or disabled without deploying code. This is what makes rollback fast.
• Targeting — flags can be enabled for specific users, groups, or percentages. This is what makes gradual rollout possible.
• Audit history — every flag change is logged with who, when, and why. When a postmortem asks "when was the flag enabled?", the audit history answers.
• SDK integration — the code checks the flag at runtime with a single function call. The check is fast (cached locally) and safe (defaults to off if the platform is unreachable).

// The flag wraps the new behaviour
if (flags.isEnabled('feature-exam-grading-grade-and-mark')) {
  // New behaviour — Gal's grading flow
  return renderGradingView(exam);
} else {
  // Current behaviour — unchanged
  return renderLegacyExport(exam);
}

Resolution gate — Flags to Release

Enough to release safely and roll back instantly.

The flag is wired, tested in both states, named correctly. The rollout plan is decided — instant or gradual. The cleanup ticket exists.

Part Eight — The Release →