How to change a feature flag from a “release” to a “kill switch”

Feature flags are great for a ton of reasons. A big one is that they enable fast and reversible decisions. 

This is true whether you’re controlling when a button is blue or green, which version of a redesigned page your customers see, or even testing different algorithms in your back end.  

But not everything is easy. While using Unleash in our own system (we do use our own product) I find myself having to deal with one of those difficult things: Changing a flag from “Release” type to “Kill switch.” 

This is a bit different from simply setting up a kill switch. We’ve already talked about that in a previous article. 

In this case we’re taking a pre-existing flag and making it do something new. Basically we wanted the flag to stop a thing instead of activating it.

Ideally we’d avoid changing the code, as that’s kind of the point of feature flags in the first place. We spent some time looking into it. Here’s what we found. 

Review: What are kill switches?

For review, this is what a release flag looks like in code: 

if (unleash.isEnabled(“AwesomeFeature”)) {

  // do new, flashy thing

}

Obviously this is before you adapt the code to include segments or constraints to target a specific group of users. For our purposes, we’ll work with this basic setup.

Anyway, what happens if your feature is fully released, but you need a way to disable the feature at any point? This is what a kill switch is for.  

This is what a kill switch looks like in code:

if (!unleash.isEnabled(“AwesomeFeatureKillSwitch”)) {

  // do new, flashy thing

}

 

Notice the ! and the new name. This communicates that if a feature flag is not enabled, then proceed with the feature execution change.

Buuuuut this is a code change, and code changes are boring. Wouldn’t it be better if we could just flip from awesome feature to kill switch without digging into the code?

Eh, it’s not so easy.

Challenges with switching feature flag types

Our initial research brought up a few challenges that we didn’t particularly care for. 

Imagine this: You keep your code the same as it is, but you still change the feature from a release flag to a kill switch:

 

• First, you’ll need to keep the kill switch enabled, because your code treats it as a release flag (remember the code change above). This means that inside the Unleash admin, the UI can be a bit misleading. Having the kill switch enabled keeps your feature on, instead of killing your feature. Weird and unhelpful.
• Second, your code would, in fact, be evaluating a kill switch, not acting as a kill switch. A distracted developer might think something’s wrong, then rewrite the code to make it look more like a kill switch. 

Pretty much things get super confusing when you don’t change the name and code.  

Also consider that you’d need to coordinate the changes with a deployment. Otherwise you’d temporarily disable a launched feature.

An easier way to change feature flag types

Here’s what we did instead:

We began by using the clone feature functionality to create a clone of our feature. The feature kept the same configuration as the original feature. This means the feature kept the same release strategies, segments, and constraints. 

What we changed were the operators, in that we inverted them. NOT_IN replaced IN, and NUM_GTE replaced NUM_LT.

This left us with two flags. When one flag was enabled, the other disabled, and vice versa. Using dependent feature flags could make this setup super simple. 

With these two flags, we could safely change the code. The old version would use the feature flag while the new version would use the kill switch. 

We found this necessary because we use rolling deployments. You’ll find this is also the case in most zero-downtime deployment strategies. 

We used feature flag metrics to validate the release flag was no longer used. It’s good that we did this, as we realized someone was still using the old flag. 

Once we fixed the situation, we removed the code referencing the old flag. 

What we’ve learned from this:

• Feature flags really do help us release better and with confidence, even when the change is a flag itself.
• Metrics are a super important step to make sure no one is using a feature flag before removing it.
• And, we were reminded of a general rule: You really shouldn’t reuse flags.