19
The introduction of Feature Flag into your system
Feature Flag is a well-known technique to modify system behaviour without changing code.
As of today, besides Martin Fowler's blog, we have a lot of posts and youtube videos to know how Feature Flag looks like.
However, if you'd like to introduce it into the system, probably you will face some issues to consider and discuss to develop your own Feature Flag.
In this article, I am going to address what came up as the issues in front of my team, and show how I lead the first version of Feature Flag of the company with the Rails code example.
My company has several backend teams and frontend teams. So the first question is, each team can have its Feature Flag system or not?
The decision was NO at that time. Why it is better to have a unified, centralized Feature Flag system as a company? That is because it becomes out of our control soon if we have multiple flagging system.
For instance, let's assume we develop a new feature A by team 1 and team 2. If we have an independent Feature Flag system, we should make sure both A's flags are in a correct status in both of team 1 and team 2 Feature Flag system. But, what if we have feature B simultaneously? What if team 3 is also involved? Easily variables would increase right after starting the operation.
However, this decision has also a drawback. Once a certain team starts creating Feature Flag Service, other teams should wait until the team provides API to use Feature Flag.
When you hear the word, Feature Flag, what comes up in your mind? It enables us to do the A/B test. It works like a circuit breaker. It provides premier features to limited users, etc.
Yes, if we say Feature Flag, it has a variety of features to be implemented. Especially if people have experienced to use sophisticated Feature Flag system like LaunchDarkly, the ideal Feature Flag would have rich functions.
To take a step forward, let's think the first implementation as simple as possible.
As mentioned in this article, it is better to focus on "Release Toggle" to allow deploying on-going code into production. Release Toggle enables us to deploy in-progress code into production. It reduces long held feature branches in your codebase.
Let's see a simple implementation of Feature Flag which implements Release Toggle.
class FeatureFlag
def self.enabled?(feature_name)
case feature_name
when 'awesome-feature'
true
else
true
end
end
endThe simplest example would be like this, but it seems not practical to operate the real-world application. So, what should be considered to introduce it into our application?
Else block of the above example is the default value that would be returned if the specified feature name doesn't exist. In this case, should we return true or false? Or, better to raise the exception?
The purpose of Feature Flag, especially Release toggle, is to make Deploy and Release independent. From that aspect, the codebase won't need to know what kinds of feature flags are defined. Meaning we should not raise the exception because the non-existence of a specified feature flag is not the exception. Further, it would be better to return false than true because in most cases, we would use a feature flag when we want to launch a new feature. If so, when the specified feature flag doesn't exist, nothing happens would be a preferable behaviour. Given that, returning false is safer to operate the real world application.
Feature Flag is magic. Once it is introduced into the product, everyone uses it to make their work easy. Eventually, there would be tens or hundreds of flags and our Feature Flag would be out of control. To prevent the worst-case scenario, having a limitation for the number of flags is a good practice. 5-10 would be a good start!
As you see in the example, hard-coding flags into the ruby file look not practical. What would be good to set them up then? RDB seems reasonable, they are reliable, add/delete operation is easy, and it's needed if we make UI. But this is the very first version of Feature Flag. Maybe we would expand what Feature Flag can do in near future. Given that, we want to avoid over-technology. From that aspect, YAML would be a good candidate to manage flags. And if that YAML file loaded during booting up the app, seems great. We can make it easy by using Rails legacy.
Following the above aspects, let's refactor the code.
feature_flag.rb
class FeatureFlag
def self.enabled?(feature_name)
if @features.key?(feature_name.to_s)
@features[feature_name.to_s]
else
false
end
end
def self.load
@setting = YAML.safe_load(File.read(config.setting_path))
@features = @setting['features']
raise "The number of flags is limited to #{config.feature_limit}" if @features.count > config.feature_limit
end
def self.config
@config ||= Config.new
end
def self.configure
yield config
end
class Config
include ActiveSupport::Configurable
config_accessor :setting_path do
''
end
config_accessor :feature_limit do
0
end
end
endconfig/initializers/feature_flag.rb
FeatureFlag.configure do |config|
config.setting_path = Rails.root.join('config', 'feature_flag.yml')
config.feature_limit = 5
end
FeatureFlag.loadconfig/feature_flag.yml
features:
awesome-feature: trueLooks way practical, doesn't it?
You would have two dimensions to expand this Feature Flag. 1. Adding new Toggles and 2. providing API for other teams. We now have the exact example as the code. It would make clear what we should do next, what we can, how long it would take. That enables to involve non-developers into the discussion!
Feature Flag is a very useful, powerful feature and it's discussed for a long time. However, there are few examples if you want to refer to implement your own Feature Flag.
Hope this article helps to solve your concerns, and can earn the huge benefits of FeatureFlag!
19