Deploying code and releasing a feature are two different days

The useful part

The engine behind the apps, the back office our customers build in, the web products around them — code moves to production at the rhythm of engineering: when it's ready, it goes. A feature has a launch: a name, documentation, support people who know it exists, sometimes a price. That's a product decision, with its own calendar, made by people who don't merge code.

How it works

• On a platform where every app runs on an engine all apps share, you don't get to conflate the two — there is no "just ship it to some users" when a deployment, by construction, reaches everyone.
• That's the whole point of the separation: the code's path to production and the feature's path to users never had to share a schedule — so neither had to wait for the other, and neither could rush the other.
• So the two acts had to be decoupled, and the thing that decouples them is the humblest object in software: a flag.
• Weeks in production before existing There's nothing exotic about a feature flag — any team that ships continuously runs some version of this, and we claim no invention here.
• The day-to-day of it is still worth telling, because it's where the two calendars become visible.

What to take from it

One configuration value kept it off, globally — for everyone except the few people building it, who used it daily, in real conditions, in the middle of real traffic, while every other visitor saw nothing.

Details worth keeping

A feature we shipped recently spent weeks in production before it existed. When a feature does start to exist, it advances...