Feature flags. Once you learn about them, you wish you knew about them many years ago. If you don’t know what they are, they’re a way of separating code deployments and feature releases. Sounds good, right?
The most basic way to use a feature flag is almost like a short term “on/off” switch. “Off” signifies “use the old version of the feature” or “show the old dashboard” and “on” can mean “use the new version of the feature,” “show the new feature” etc.
In my experience, this is generally the extent that everyone uses feature flags. They never move past the basics. Moving past this requires you to think differently. It requires thoughtful planning.
Let’s run through an example. Imagine we have a dashboard on our platform. We want to refresh this dashboard for users but we need to manage lots of moving pieces in the refresh. The first step we need to take is to create a “master” feature flag that controls everything. Then, creating a feature flag for small chunks of the dashboard. By planning and creating feature flags this way, we can slowly roll out sections of the new dashboard either all at once or in individual stages.
It also allows for damage control. Rather than disabling or using the “kill switch” for the “master” feature flag, use it on the smallest component that’s causing issues. By spending 5 minutes to plan out our feature flags, we’ve now added an effective mitigation strategy to handle bad feature releases.
Taking this example further, some (if not most) feature flag platforms allow you to store strings, numbers and even JSON! This gives you more flexibility than you may think. How would you use this? Let’s explore using a JSON object. This could be used to display some sort of notice on your landing page. It may contain a URL, the specific colour it should have in the background, the text to display, etc. The possibilities are endless.
Now, taking this one step further. Feature flags can (and should) be used with specific attributes to target different groups of users. Think about it. Your favourite apps most likely have a feature “preview” or “beta access” section where you can opt in to trying new features before they’ve been widely rolled out. Setting up the attribute targeting with role based authentication is one way of achieving this.
To summarise, don’t just think of feature flags as “on/off” switches for releasing new features. They’re more powerful than you may realise. Spending just a few minutes to plan your feature flags can have significant benefits. They won’t be immediate, but it will be present in the long term.