Out of all of the questions I’ve received on feature flags from analysts, potential customers, event attendees and colleagues, perhaps the most consistent topic is around the lifecycling of flags to minimize technical debt. It’s a natural concern when considering how to scale the usage of feature flags across a large organization. How do I know when to remove a flag from my code? What flags could be candidates for removal? How do I know a particular flag is even being used?
Feature flags have clear benefits to improving release velocity while reducing risk and allowing product teams to safely get early feature feedback from end-users in production. However, they without a doubt also introduce a new level of complexity in development as a software version number is no longer the “single source of truth” - multiple versions of a feature can now be running in production at once. At a minimum, this can equal bloated code over time. At worst, it can equate to mismanaged user experience and unknown flag status, opening the door for even larger errors to arise over time. When larger organizations are potentially managing hundreds or thousands of flags at once, the potential for errors (and the risks associated with mismanagement) begins to compound.
So what are companies to do? There are, of course, good old fashioned “flag hygiene” practices that any company can undertake to help simplify the usage of feature flags. This guidance is mostly common sense activities like common flag nomenclature and documented creation and removal processes across development teams. While these practices are certainly helpful, they can only do so much once flags are live in the system if they were created against policies that are ultimately just recommended guidelines.
Feature Flag Lifecycling Best Practices
Realizing that development teams need an easier in-tool system for visualizing and managing flags, we’ve created a new flag status column in our CloudBees Feature Management dashboard to ease this process along. Now, when you hover over flag status in your dashboard, you’ll see one of the statuses seen below.
Flag status provides live updates on how flags are being used along with corresponding recommendations for actions to take.
There are five flag statuses:
Active - This flag is receiving impressions with mixed values in the last seven days (leave it alone, it’s working!) Impression data can be seen in that column further on the right.
Stale - This flag is receiving impressions, but they’re all the same. (This feature is likely fully rolled out, you might want to remove the flag.)
Inactive - This flag has received no impressions in the last seven days. (It’s a warning sign that you should check on what is going on and probably should remove it.)
Setup - This flag has never received impressions (You should either finish setting it up or remove it.)
Permanent - Impressions aren’t being counted. (You expect this flag to be in place long-term.)
It’s worthwhile to spend a moment more on permanent flag status. If you’ve read Pete Hodgson’s famous blog on feature flags on Martin Fowler’s website, you’ll know that feature flags can be put in one of four categories of use: experiment, ops, release and permissioning. Experiment and release toggles are short-lived and are exactly the types of flags we are monitoring for impressions to determine if they are still being used or are ready for removal. Ops and permissioning flags on the other hand are long-lived and are put in place to provide the ability to change the behavior of an app long-term (i.e. a killswitch), but with little expected day-to-day change. Since flag usage is typically known upfront, we provide the ability to mark a new flag as permanent so that it is removed from the flag status scrutiny that all other flags are subject to. You can see this in the screenshot below.
Mark long-term flags as permanent so that they removed from the flag status evaluation.
Finally, it’s important to note that you can now filter all of your flags by flag status in the buckets described above so that you can easily see all flags that are stale or inactive for fast flag lifecycling on a regular cadence. Adding feature flags as a permanent part of software release is critical for achieving enterprise progressive delivery and the potential for technical debt should not discourage you from doing so.
With our new flag status feature, flag lifecycling just got that much easier! See this in action in the three-minute demo below.