Wellfire Interactive // Django consultants for your existing Django site

Flip ya for real: Feature Flipping as a Maintenance Strategy (This Old Pony #26)

Feature flipping is a technique by which a block of code is conditionally included or executed for a user.

This can look like a site wide on/off switch, a more complicated set of filtering logic including randomization, or somewhere in between.

It’s a must-have strategy in your toolbox if you’re working with a SaaS product or any other kind of customer-centric site.

Let’s motivate this claim!

Why bother?

Feature flipping adds extra code to your project and it requires its own maintenance. You’ll need to remove code that you’ve added just for the feature deploy, and it can complicate testing.

And yet in many situations it’s more than worth this minor hassle.

Depending on how it’s deployed, feature flipping can:

  • Enable basic user testing with specific users or groups of users - on the production site, using production data
  • Allow you to test the performance of a new feature in the wild, with real customers and in the real production environment.
  • Easily revert changes if necessary, for any reason
  • Allow making a new feature live without a separate deployment Testing that a feature actually satisfies what users need, reducing deployment risk, allowing for product owner control over feature roll out timing… what’s not to love?

    And for legacy Django sites?

    If you’ve had a product in the wild for a while, customers will be used to how things look and work, whether you like it or not.

By turning on a new feature or changing how one works for a select group of customers, you can gather feedback - directly or indirectly - to make course corrections so that the full deployment is well received.

With almost every legacy Django project we’ve encountered, deployment is always a pain point. It might be for technical reasons, for cultural reasons, but whatever the reasons feature flipping allows for much for iterative deployment with an “off” switch that beats deployment rollback any day of the week.

How to implement

There are several ways of _implementing _feature flipping in a Django project.

  • Use an environment toggle-able environment variable
  • Use a third-party app like Django Waffle[0] or Gargoyle[1]
  • Write your own flipping app For a one-off implementation that is site-wide, for example, you can probably use a simple setting variant like an environment variable. The downside is that it won’t be _quite _as accessible to non-technical staff, but it’s dead simple to use. You should set this in your settings file and then reference this value from settings, in views, context processors, etc.

If you’re going to be implementing feature flipping more than once, a third-party app is probably your best bet. We’ve used Django Waffle on several projects and it probably fits 90% of feature flipping uses beautifully. Gargoyle works too, with some additional under-documented filtering features.

And yes, you could roll your own. It’s very unlikely you’d need to do this, but if you need more power than Waffle offers and don’t want to use Gargoyle then this is your next avenue.

The main reason to write your own is if you need more expressive conditionals and need these to be available in an intuitive way for non-technical users in the admin. E.g. Waffle lets you select for 1 or more individual users or groups (auth.Group) if you want. I was reminded of this in a blog post about feature flipping with Waffle and I am going to tell you that using groups will _work _but is not a great idea.

Look, it’s not going to break anything, but if for any reason you’re using groups to manage permissions - the purpose of groups - then this could cause serious confusion. A “better” filter would be based on something like _tags _on a user profile or customer account model… but now we’re talking custom development.

About A/B testing

I should say a word about A/B testing before wrapping this up, because feature flipping is a core component of A/B testing (but remember, not vice versa).

There _are _tools for A/B testing in Django and no we haven’t used them. In the past we researched these and found that for the purposes of app-integrated A/B testing the feature flipping tools were more than sufficient. Waffle provides some randomization filtering, and if you really want to get funky you could chain a switch or feature flag with some custom middleware to add more fine grained randomization.

If you’re A/B testing design or copy (e.g. for landing pages or sign up pages) you’ll probably want to take a look at a dedicated, Javascript based third-party service.

(And make sure you’ve got the numbers to justify the test!)

On today, off tomorrow,

[0] Django Waffle https://github.com/jsocol/django-waffle
[1] Gargoyle https://github.com/YPlan/gargoyle (note that Disqus are the original authors but no longer maintain their repo)

Learn from more articles like this how to make the most out of your existing Django site.