Basic concepts on feature toggles, feature flags Aug 27 2018

There are simple concepts that can significantly improve our projects, one of these concepts is Feature Toggles. In this post, I will explain the basic idea behind Feature Toggles and a basic implementation example.

Feature toggles (aka, flags, flippers, bits), in simple terms, are a way to control the flow of our code and make decisions to run specific versions/implementations of it. What this means is better understood by an example, so let's get to it.

Case study for Feature Toggles

Imagine that we are working on a new implementation of our application dashboard, but we don't want to ship it to all of our users right away. We would prefer to test it first and make it available to our developer team or maybe present it to just a small set of clients. How can we go about doing this?

Well, we could set up a new server and push the new code there, but this sounds like a lot of extra work and probably additional expenses. The solution: Feature Toggles, what if we could just tell our code only to show the new dashboard if the user is part of the group "developers", or if the IP address comes from our office, or any other "flag" that will allow us to decide to show new features or different implementations of our code. That is the basic concept of Feature Toggles, we can toggle features on and off based on some criterion. Let's see a basic example of how to implement it.

Basic implementation

The most straightforward implementation would be using any control flow that our programming language provides. I'll use Ruby code for the example.

Let's say we currently have our dashboard function like so:

1
2
3
def dashboard
  # the current logic to render the dashboard
end

And for the last few weeks, we've been working on the new dashboard. We now have a new_dashboard method that will render the new dashboard:

1
2
3
def new_dashboard
  # all the new logic that will render the new dashboard
end

As I mentioned before, feature toggles are not complicated; certainly, we can make things much more complex but let's stick with the basics. To implement our feature toggles, let's use cookies. We will check the value of a variable in a cookie and based on that value decide which dashboard to show.

For this example, it doesn't matter how we are setting the value, what matters to us is that we can somehow tell our application the condition that will help decide which dashboard to show. We will add the logic of the feature flag in our old dashboard method.

1
2
3
4
5
6
7
8
9
10
11
def value_from_cookie_is_new_dashboard?
  # the logic that will check if the client has the cookie set
end

def dashboard
  if(value_from_cookie_is new_dashboard?)
    new_dashboard
  else
    # the old implementation of our dashboard
  end
end

And that's it, it is not a sophisticated approach, but it gives us great flexibility. I've seen many projects that would benefit from a quick way to show some users (managers, real users, testers, other developers, etc.) a new feature, even if it is not 100% polished or entirely ready for production.

Benefits from the flexibility

I've seen cases where the code remains in a feature branch (a git branch) for a very long time, becoming stale and never sees the light of day. On other cases, improvements are kept from release because we are waiting to make a big push to production. Using feature toggles is a way to minimize this problem, giving us the option to release specific functionality in increments or just to a particular group of users.

In some DevOps circles, it is proposed that if we wish to have continuous delivery (CD), we should separate feature rollout from code deployment and one way of doing this is through Feature Flags.

My implementation in the example code is quite basic, but there are more sophisticated ways of doing it. One way is using an in-memory flag or using a key-value database like Redis. I would recommend starting with a simple approach first, then moving to more complex solutions when they have outgrown our initial implementation.

One detail I would like you to keep in mind is that having all that extra logic in your code can become a mess quickly if you don't maintain it.

Feature toggles should not stay in your code for a very long time, a few weeks at most, it should only be used while you are still exploring the capabilities of your new feature. Once the new code has been tested and is ready to become your default, remove that feature toggle.

I would recommend having a way to identify where you have a feature toggle, for example, add a specific comment that you can search for in your codebase and will show you all the places where feature toggles exist. For example:

1
2
3
4
5
6
7
8
def dashboard
 # FEATURE_FLAG_BRANCHING
  if(value_from_cookie_is new_dashboard)
    new_dashboard
  else
    # the old implementation of our dashboard
  end
end

If we do a search for FEATURE_FALG_BRANGHING, we will find that we are using a feature toggle and decide if we should remove it or keep it. Really, keep an eye on the feature toggles don't let your codebase become messy, it will cause headaches.

Adding a comment is one way, but if you are using a library or decide to create your own to handle the flags, you can probably search for the method of your library that handles the validation.

Let me give you an example of a basic implementation of a library to handle Feature Toggles.

1
2
3
4
5
6
7
8
9
10
11
12
13
class FeatureBranchHandler

  def initialize
    @feature_branch_conditions = {}
  end

  def set_feature_option(:key, :value)
    @feature_branch_conditions[:key] =:value
  end
  def feature_is_set?(key)
    @feature_branch_conditions[key] || false
  end
end

And then we would use it like this:

1
2
3
4
5
6
7
8
9
10
11
FBH = FeatureBranchHandler.new()

FBH.set_feature_option(key: :use_new_dashboard, value: true)

...

if(FBH.feature_is_set?(:use_new_dashboard)
  # render new dashboard
else
  # render old dashboard
end

Because we will use the feature_is_set? method to do the toggle, we could search for feature_is_set? and we would find all the code that is using feature toggles. Again, these are just simple examples, if you would like to read more about the topic, I would recommend you read Martin Fowler’s article on feature toggles.

As always hope this helps someone out there. Remember to make things simple, let us not overcomplicate concepts and alienate people form software by creating an environment where obscurity is prefered over simplicity.

Let me know what you think, and if you have any questions, send them my way.