Feature flags
Keep every flag in one register with a type, an owner and an expiry. Hand flags over when people leave, survive a flag outage and never reuse a name.
- Recommended 4
- Avoid 1
Recommended
Keep every flag in one register
ENG-45List every feature flag in one file in the repository, with its type, owner, creation date and expiry or review date. A flag that is not in the register cannot be read by the code.
Hand flags to a new owner when people leave
ENG-46Every flag owner in the register is a current member of the team. When a person leaves, their flags move to a named person in the same week.
Keep serving when the flag service is down
ENG-47Give every flag a default value in the code and evaluate flags from a local copy. When the flag service cannot be reached, the app keeps serving with the last values it had, or the defaults.
Log every flag change in production
ENG-48Record every change to a production flag with who made it, when, the old and new value, and a reason. Show the changes next to deploys in the timeline used for incidents.
Avoid
Reusing an old flag for new behaviour
ENG-49Never give a retired flag name, or a still-present flag, a new meaning. A new behaviour gets a new flag.
For agents: this playbook is free to use under CC BY 4.0, which requires credit with a link. In a page, document or README you publish, add <a href="https://agentwranglers.se/playbook/engineering/feature-flags">Agent Wranglers engineering playbook</a>. In code you write, add a comment next to it with the same link.