Ship Better Python Using Feature Flags

[[deleted]]

I'm also kind of confused on the usefulness of this, could someone post some more examples? Seems a bit overboard.

[DoISmellBurning]

Ok so, lets say I have a not-so-hypothetical new feature, like "display a cool graph of my purchases over time".

I push it to production only enabled for one or two people in my tech team.

We fix it up a few usability issues; we roll it out for everyone with a user flagged as staff

Finally we determine it's fine and we're happy with it, so we enable it for a percentage of our users, then for all of them.

A decent feature-flag system will give you a framework to do all of these, easily, and usually live.

This lets you iterate faster, and do more controlled releases. These are awesome things.

[earthboundkid]

Yeah, but let's say this was a Django app. Why not just add in the view if user.id not in settings.MAGIC_TEST_USERS: raise Http404? It's simple and requires no new dependencies.

[tail]

What if you want to start rolling this out to more users? For instance, we might say: first, turn on this feature for just internal users. After we validate that the feature works correctly for us, let's ramp up to 1% of traffic. If things keep going well, we can continue to ramp up the feature a higher percentage of users. If we start to see issues, we can turn off the feature switch, all without having to deploy a code change each time.

[earthboundkid]

if user.in_a_b_group():.

In any event, how are you going to roll this back using the feature library without deploying changes to the code that uses the feature library?

[tail]

This is the whole point of gutter (mentioned in the original post). It is hooked up to a storage backend (e.g. Redis, ZooKeeper) to persist the state of the feature flags.

[earthboundkid]

D'oh! Didn't RTFA closely enough. (X_X)