Release discipline

Feature flags are production code

A flag is not a sticky note you slap on risky code. It is a branch in production. Name it, test it, own it, and delete it before it becomes archaeology.

~6 minCoding
scroll
01 · the promise

Flags decouple deploy from release

The magic of a feature flag is simple: ship the code now, expose the behavior later. That gives you dark launches, internal testing, staged rollout, instant rollback, and fewer heroic deploy windows.

checkout.ts

That branch is live in production even when the new path is hidden.

change looks calm

A tiny patch rarely touches only one thing. Push it and watch the review surface appear.

02 · the cost

Every flag doubles a path somewhere

A flag creates at least two realities: on and off. Sometimes it creates many more: user cohorts, regions, plans, experiments, internal overrides. If you do not test the important combinations, the rollback path can be the broken path.

change confidence lab
guessy
safe0
fragile: this change still depends on hope and a lucky deploy

Flip the switches and watch the story turn into a tiny operating model.

0minimum paths for every boolean flag
0named owner who deletes it
0days before many release flags should be questioned
03 · the hygiene

Put metadata next to the decision

A useful flag has a purpose, owner, creation date, expected removal date, and safe default. Without that, nobody knows if the off path is still real or just a museum exhibit with traffic.

zsh · stale flag audit

This is the job that saves you six months later.

04 · the exit

A flag is done when the branch is gone

Do not celebrate rollout at 100 percent and leave the switch behind. The actual finish line is removing the dead branch, deleting the config, and shrinking the test matrix back down. Flags are leverage. Unowned flags are debt with a UI.

source trail