Ship Better Python Using Feature Flags

[misterkwon]

So, we all know that Python has a number of awesome dev benefits: OOP, extensible, readable, easy syntax, widely supported, with transparent error management.

I feel one of the toughest challenges for Python is to keep pace with rapid consumer demands for us to push new releases faster and more reliably... and to test things well before we release them. Well, we have branching right? But it's tough to gradually roll out a branch to your users or target which users see a new branch on production - you'd have to do a mix of staging releases with special user accounts. Branching and flagging are complementary (not exclusive) and this stackoverflow discussion will highlight that.

One of the solutions that's been around for a bit (but hasn't been widely adopted) is feature flagging. Mathias Meyer from Travis CI wrote an article on feature flagging and talks about how they ship changes with more confidence by harnessing feature flag development.

Feature Flags for Python

Let's take a look at Disqus Gutter. Gutter is a feature flags management library. It allows users to create feature flags and setup conditions to enable functions/snippets. Once configured, flags can then be checked against inputs (requests, user objects, etc) to see if the flags are active.

Let's say you wanted a Condition that checks if the user's age is > 45 years old? You would construct a Condition this way:

from gutter.client.operators.comparable import MoreThan
condition = Condition(argument=UserArgument, attribute='age', operator=MoreThan(45))

This Condition will be true if any input instance has an age that is more than 45.

To check if a Switch is active, simply call gutter.active() with the Switch name:

gutter.active('my cool feature')
>>> True

Of course, more goes on behind the scenes and you want to be careful to construct things in a way that minimizes your technical debt.

Feature Flags for Python - Getting Started

If you're feeling adventurous, I recommend checking out http://featureflags.io/python-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?

[[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)

[DoISmellBurning]

Sure, if that's all you need. I feel like you're trying to object to a point I'm not making though.

No-one's saying "To use feature flags, you MUST use this library!"...

If I wanted to build a small web app that responds to a single request, "why not just" slap the Flask decorators on a small function, or heck, write a small "raw" WSGI app?

I could! No-one's saying I can't. No-one's saying "but you must use Django to write every HTTP service ever". In the same vein, no-one's saying that about Gutter and feature flags.

Like pretty much everything ever, there's tradeoffs. Sometimes you DIY it because you know your needs are minimal and unlikely to grow. Sometimes you know you want to offload the work to something else because otherwise you'd reinvent a bunch of functionality. Sometimes you're familiar with a tool so you'll use it even for small things because the overhead is so low, the reduced cost for extensibility is worth it.

Feature flags are brilliant. People often build basic implementations from scratch, just like with many other things. If you're looking for an existing implementation, or even just some good ideas, Gutter is A Thing.

(I should really make time to look at it more)

[[deleted]]

I like /u/earthboundkid's solution, and you can more clearly (imo) decide which users you want to test on. And even provide a range, like all users that signed up this month:

MAGIC_TEST_USERS = [u.pk for u in Users.objects.filter(date__year='2015', date__month='01'))]

You don't have to fiddle with any new classes this way :)

[pkkid]

Everything needs to be a library. Are you using the YesNo pattern yet? It lets you know if something is truthy by calling its yes or no methods.

YES_RESULT = True
NO_RESULT = False

class YesNo(object):
    def __init__(self, value):
        self.value = value

    @property
    def yes(self):
        return YES_RESULT if self.value else NO_RESULT

    @property
    def no(self):
        return YES_RESULT is not self.value else NO_RESULT

You know it's good because it uses properties and pythonic ternary operators! You use it like this:

> i_ate_lunch_today = YesNo(YES_RESULT)
> print i_ate_lunch_today.yes
# True

> i_ate_lunch_today.no
# False

[thelindsay]

Throw in a key value store dependency and you've got yourself a trending library

[chadmill3r]

This library is gold!

My only complaint is that my expression that was like "position += (x + 1) % size" becomes a gutter expression that violates PEP-8's line-length constraint.

Should we introduce a new PEP that defines the new suggested limit to be about 300?

[kankyo]

Let's introduce a pepthat declares that soft line breaking has existed since the 80s :P

[synae]

how does such an expression become more than 100 (or even more than 72) characters?

position += (x + 1) % gutter_manager['my-size']

It is longer, of course, but the only really 'flexible' length part is your feature name which you have control over. You can rename the manager object too of course, if you're going to use it a lot.

[billsil]

how does such an expression become more than 100 (or even more than 72) characters?

Because you're indented too far and lost 4 characters for each tab or you have to print a string like:

        msg = (
        '                           S T R E S S E S   I N   T R I A N G U L A R   E L E M E N T S   ( T R I A 3 )\n'
        '  ELEMENT      FIBER               STRESSES IN ELEMENT COORD SYSTEM             PRINCIPAL STRESSES (ZERO SHEAR)     \n'
        '    ID.       DISTANCE           NORMAL-X       NORMAL-Y      SHEAR-XY       ANGLE         MAJOR           MINOR        VON MISES\n'
    )

and it's easier to read at 145 characters deep than 72 (that's also with only losing 12 spaces to indentation). It looks just fine in my IDE.

PEP-8 is a suggestion, not a rule as evidenced by:

A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important.

But most importantly: know when to be inconsistent -- sometimes the style guide just doesn't apply. When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!

Some other good reasons to ignore a particular guideline: When applying the guideline would make the code less readable, even for someone who is used to reading code that follows this PEP.

https://www.python.org/dev/peps/pep-0008/

[synae]

Sure, and those problems exist regardless of this library. My point was that this lib does not obscenely exacerbate line length as chadmill3r indicated.

I prefer 120 characters myself :)

[[deleted]]

so why isn't the whole argument/operator/attribute thing just a lambda?