Feature Flags & Trunk-Based Development Vocabulary
Practise vocabulary for feature toggles, flag types, percentage rollout, flag lifecycle, and trunk-based development.
0 / 5 completed
1 / 5
A release flag (feature flag) in trunk-based development is used to:
Release flags enable trunk-based development: code is always merged to main (avoiding long-lived feature branches), but wrapped in a flag that is disabled in production. The flag is enabled once the feature is ready for release — decoupling deployment from release.
2 / 5
The difference between a kill switch and a release flag is:
Kill switches are operational safety valves: 'If this payment provider starts returning errors, flip this switch to disable the feature and fall back to the previous provider.' Unlike release flags (used during development), kill switches remain in production code as emergency controls.
3 / 5
Percentage rollout of a feature flag means:
Percentage (canary) rollout: observe each increment for errors before expanding. If the 1% cohort shows 2x error rate, roll back immediately — only 1% of users were affected. This is the core risk mitigation pattern for high-impact feature releases.
4 / 5
Flag debt in feature flag management refers to:
Flag debt compounds: each old flag is an additional code path to test, adds cognitive load, and may interact unexpectedly with new flags. Best practice: flags have a documented lifecycle with a cleanup date. After 100% rollout, the flag and its old code path are deleted in a follow-up PR.
5 / 5
Trunk-based development means engineers:
Trunk-based development: feature branches live for hours or at most 1-2 days. Merging frequently to main reduces merge conflict risk and enables continuous integration. Long-lived branches (weeks/months) are the main source of painful merges. Feature flags compensate for incomplete features on main.