A team adopting feature flags may be surprised to discover the broad applicability of what seems to be such a simple technique. Feature flags enable continuous delivery, dark launches, A/B tests, canary releases, kill switches, beta programs, and more.
This broad applicability often leads to an explosion of feature flagging activity. At the same time as flags are blooming throughout the codebase, other teams within the organization are noticing the value of the technique and start applying feature flags too. It’s not long before the list of feature flags starts to feel a little overwhelming, and the conditional statements littered through a codebase begin to chafe. No one is quite sure what some flags do. Is this flag even being used any more? Which team owns it? Is this flag for an A/B test, or a dark launch? Should I test my code with both variants of this flag, or not? If I want to turn off this flag, are there any other flags I need to turn off too? Is that team over there *really* using feature flags to protect access to an admin UI?!
Luckily there are some simple management techniques which help keep things under control. In this talk, continuous delivery consultant Pete Hodgson will introduce some of them. He’ll show how categorizing and namespacing your flags communicates the status of each flag and which team owns it. He’ll cover a formal flag categorization scheme, showing how it can greatly clarify the lifecycle and stakeholders of any given flag. Pete will also share some practical tips for keeping the number of flags manageable and ensuring that old flags are retired and removed. Applying some theory from lean manufacturing to reduce inventory can be effective, as can the simple act of placing an expiry date on a flag.
Originally recorded on Feb 15, 2018 from the Split Meetup.
Speaker: Pete Hodgson