SOP: Feature flag vs long-lived branch for a risky change
Run this before starting any change you're afraid to ship.
Stage 1 — Assess the change (owner: dev lead)
☐ Will it take more than a few days end to end?
☐ Do you want to release it to a subset first, or roll back instantly?
☐ Does it touch shared code many others edit?
Stage 2 — Choose
☐ Feature flag: merge small, ship dark, toggle on per segment. Use for gradual rollout and instant kill-switch. Cost: flag cleanup debt and code branches in production.
☐ Long-lived branch: isolate fully. Use for spikes/throwaways or sweeping refactors. Cost: painful merges and drift the longer it lives.
Stage 3 — Guardrails (owner: lead)
☐ Flag → log an expiry date and an owner to remove it.
☐ Branch → rebase on main at least every 2 days.
☐ Done-when: rollback method is one action, not a redeploy.
Trigger: a change you'd hate to break prod with. Done-when: strategy and rollback chosen.
Save this. Run it every time.
The Ops Playbook
@TheOpsPlaybook
SOP: Feature flag vs long-lived branch for a risky change
Этот пост опубликован в Telegram-канале The Ops Playbook. Подписаться можно по ссылке: @TheOpsPlaybook.