When I first started working on Flipper Cloud, one of my first questions (demands?) was a way to be more confident about whether or not it was safe to delete a feature flag from the Flipper interface. It took a fair amount of infrastructure work, but it's almost ready. Hopefully this will mean a whole lot fewer feature flag fails.
We've had a robust feature overview page for projects for a little while now, and it certainly helps to identify potential feature flag removal candidates, but it doesn't provide any reassurance of the safety of removing a flag.
subscriptions tag that's fully enabled in production and mirroring elsewhere. And since it's tagged pending_deprecation, it's a likely candidate for removal. If the feature overview page helps draw attention to stale flags, that's a start, but we still need some reassurance that nothing will break if we do remove it. We've been working on that, and I was able to really use it for the first time today.
I just deleted two feature flags that we had removed from production some time ago, but I had been waiting for us to add interface elements that shared when a feature was last checked in production.
So if a feature was checked within the last hour, it's pretty likely that there's still some code in production that's using it. Or, if it hasn't been seen in a couple of days or weeks, that provides some peace of mind that it's been fully extricated from the code.
With Flipper's new telemetry, we can see when a flag hasn't been requested in production (or any environment for that matter) for a long enough window that it's safe to remove. That creates a lot of peace of mind when cleaning up stale flags.
We're still getting everything dialed in internally, so it's not available to everyone just yet, but I wanted to show how it made it less stressful and tedious to finally remove some old flags. We'd like to take it a step further and make clear recommendations about whether a flag should be ready for removal, but that will take some more work.
For some frequently checked flags, one day might be enough to be confident they're no longer in production, but for a flag that may only be checked once per month, it's not enough to say it's ready after only one day. Similarly, some flags are used as virtual circuit breakers and should never be removed. (For a circuit breaker, imagine being able to temporarily disable a poorly performing feature or switching from one email provider to a backup email provider if the primary is having trouble.)
So we'll keep iterating, but soon we'll be shipping some peace of mind to any teams that have been hesitant to remove those old feature flags. It's already helping us, and we're excited for it to help you too!