Feature Flagging in Ruby
Using EightBall

Your team is working on a revolutionary new feature. It’s a very exciting time at work, but you know that, no matter how many precautions you put in place and how many tests you write, introducing a brand new feature to the production environment always carries at least some risk with it. What if it doesn’t scale the way you thought it would and you need to turn it off temporarily? Rolling back can get complicated, but rolling forward can take too long. Wouldn’t it be great if you could just… flick a switch?

You need feature flags.

Hold Up – What Are Feature Flags?

Sometimes called “feature toggles”, feature flags are a strategy for conditionally showing or hiding features in an application. Feature flags, in one loose form or another, have been in use since the dawn of Man (think of how a video game might handle expansion packs, or that horrible code your co-worker you wrote that only runs if (user_id == 86)).

Martin Fowler, as usual, has an excellent article on the subject dating back all the way to 2010.

In general, you would use a feature flag to temporarily enable, disable, or otherwise modify features in your application based on certain criteria. You could run a beta test with some customers who are especially interested in the feature; you could modify your subscription model for a set period of time to analyze the impact on revenue; you could deploy a half-finished feature so another company you are working for can start developing the UI — the sky’s the limit.

Before we get ourselves all worked up here, it’s important to remember that feature flags are a form of technical debt. You need to have a solid plan in place to include them safely, gather the data you need, and remove them once you are done. Otherwise, your code will become a hard-to-follow mess of branching statements, not to mention that testing all the permutations will become increasingly difficult.

You Should Always Re-Use Existing Solutions…So We Wrote Our Own

We needed feature flags at Rewind to introduce a shiny new feature. “Easy,” we thought. “Let’s go find an existing feature flagging solution that works in Ruby”. As we found, there are existing solutions. Lots of them, actually. The problem was we weren’t particularly interested in paying hundreds of dollars a month for someone to host a configuration file for us, or spinning up and maintaining an entire server to answer yes/no questions, or tying our entire data model to the feature flagging system. None of the solutions we evaluated met our criteria: free, easy, non-intrusive. Maybe we’re picky.

EightBall: Because You Ask It Questions

“Magic 8-ball, should this person have access to our world-changing beta UI?”

We ended up writing and open-sourcing EightBall, a small Ruby gem to load up, parse, and answer questions about feature flags. In our case, we store a JSON file behind an auto-invalidating CloudFront distribution to make it quick and easy to update.

Our JSON file looks something like this

[
  {
    “name”: “NewFeature1”,
    “enabledFor”: [{
      “type”: “list”,
      “parameter”: “userId”,
      “values”: [86]
    }]
  }
]

and configuring it is simple:

EightBall.provider = EightBall::Providers::Http.new <CloudFront URL>
if EightBall.enabled? ‘NewFeature1’, user_id: user.id
    puts ‘Yup!’
end

If you have questions, find a bug, or have an idea on how to make EightBall better, feel free to reach out to us (or open a PR!).

https://github.com/rewindio/eight_ball