Introducing Helioth: Feature Flipping Ruby Gem

Your application keeps getting bigger and bigger, the number of features increase and the customer base grow exponentially! Everything is fine, right? Pretty much, but with more features, more releases and more customers we tend to increase the rate at which a problem will occur.

Let’s imagine a feature you are launching is bugged (no this never happen!) or is not yet fully ready, but your product team is pushing for a release? This is when it starts to get messy and developers don’t like that!

Starting digging into this problem I found out I wasn’t the only one (shocking!) and also that a whole concept to manage those problems called Feature flipping existed. Let me explain you some of this concept, then dig into real use cases and eventually how I tried to tackle it with my own Ruby Gem Helioth

Feature flipping concept

As I said this concept is not new, in fact it was (first) introduced by Flickr in 2009 in this blog post.
The idea is pretty simple and I like to resume it as:

Having a way to enable or disable a feature in a blink

So how do we make that happen?
First you need a simple interface where all features are described (a configuration file, database etc.). On this interface you should be able to turn each feature status on and off and your app should automatically be impacted. One important thing to remember is that you shouldn’t change any of your application code during this process!

Let’s be fancy and from now on call this concept a Pattern. This feature flipping pattern is also known as:

• Feature flag
• Feature bucket
• Feature toggle
• etc.

Use cases

We introduced earlier the idea to use this pattern to enable or disable a feature in case of emergency. Of course there is more granularity to this use case. Let me introduce you two of them which will be the foundation of what’s coming next.

As a SaaS company when we ship code all our customers gets it at the same time which is pretty cool and one of the few reasons why SaaS is awesome! But we all have very important customers and even more important one (not that all customers are not important!).

I think you see where I’m going! Wouldn’t it be a great to be able to tag the importance of a customer and correlate it with the release stage of a feature? When everything will be fine and well battle tested it will be time to flip the feature to a full production phase affecting even the most important customers!

An other use case that we encounter is related to localization. Our platform is localized in 6 langages and it can happen that a feature is ready, but not yet localized for a specific language. Business and Product departments are pushing for a release and again feature flipping pattern is a pretty good answer. This time we could flag each feature with a set of locales and depending on the user language we enable the feature or not.

Those two use cases are some of the most concerning one for me as running a B2B SaaS Application.

Implementing this pattern

Now that we know the pattern and have some use cases it’s time to get technical!

We said it has to be easy and not impact the full application code. In order to do that we talked about describing the feature set. In fact, we are looking for more than a description, but more a framework. This way the application should implement as little logic as possible, and only make simple call as:

if is_enabled?(:feature)
 #do this
else
 # do that
end

By mixing those requirements and our use cases, let’s right down some of know facts:

• An app has users
• An app has features
• Users are linked to locales (language, ex: :fr, :en, :zh)
• User have a status (ex: standard, important, critical)
• Features also have a status (ex: beta, pre-release, production)
• Features have locales (= localized in x languages)

Here is everything needed to build a description framework! Once in place our application shouldn’t do anymore than asking if a feature is enabled or not while delegating all the logic to this framework.

Ruby / Rails implementation (Gem)

I found many Gems that implement this pattern and (even) some very nice one (ex: flipper, Flip, rollout etc.), but in fact none of them covered my use cases. Decision was made, I decided to build my own Gem and push the concept a little bit further.

One of the main difference with my implementation is the way the decision logic is handled. I decided to put more logic inside the description file by setting a set of status for every objects (feature, user, instance) and then set their relations. At the end I think it’s much easier to read and maintain and give you more granularity.

Like I said the most important thing was having a simple and easy description process. In order to do that I chose to build the gem around a DSL. This DSL is the only thing the developer need to write and all the flipping logic is built behind the scene using it. Using a DSL was not only to be fancy but also to make the process readable and easy for any developers:

To find out more about how it works checkout Helioth Github repository

Have fun and please give me your feedback to improve it!