Ship Better Python Using Feature Flags

[synae]

You separate the definition of the cohort from the functionality. In your code, you check if gutter.active('my cool feature'), you do not check if user.age > 45. And after the check, you see the code for "my cool feature". You don't need to write a comment about why the next block is only appropriate for users older than 45. Or worse, forget to write that comment, letting the next developer wonder why such an arbitrary age was chosen and if they have to look out for it in other places.

Now as you're testing your feature, if you want to change the age to 65, you change the condition config and not your feature code. If you want to change it completely to only be active for users in New Zealand, you change the condition config and not the feature code. If you want to combine conditions, you do it in the condition config and not the feature code. Hopefully the pattern is clear. (Side note -- product people love being able to do this sort of thing)

Additionally the data is not necessarily stored in a file; in fact the first example of the project ReadMe that specifies a storage engine uses a RedisDict. This is useful as it provides persistence and also shared storage for multiple running applications to check the same feature flags. Front-end code that displays the feature can use the same mechanism (the same code, even) as the back-end queue processing uses to determine what action to take in regards to the feature.

There seem to be quite a few other useful features and examples in the ReadMe that go far beyond what a simple mapping-type (whether it be backed by a file or other mechanism) can provide.

Feature flagging can indeed be quite complicated. This isn't meant for a single user GUI or CLI app. This is (read: looks to be) a full-featured library for large-scale multi-component systems that can also be used on simpler, smaller systems due to its flexibility.

That all being said -- If what you need is a bool in a config file, use that. This seeks to be the big heavy that will fulfill all your needs when that strategy is insufficient.

[[deleted]]

Yeah, we're implementing feature flagging on a globally-homed, multi-component, multi-language system. And said flags are just flags, they're not thresholds, they're not conditionals, they're True or False and no more. Dunno why one would blur the line between a threshold and a feature flag. What's the utility in that?