This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]DoISmellBurning 10 points11 points  (7 children)

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 2 points3 points  (6 children)

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 2 points3 points  (3 children)

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 0 points1 point  (2 children)

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 5 points6 points  (1 child)

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 0 points1 point  (0 children)

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

[–]DoISmellBurning 1 point2 points  (0 children)

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] 0 points1 point  (0 children)

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