The last few days I spent some time programming on a side project I was keen to work on. Part of that project was working with feature flags.
In a usual developer workflow, you work on a new feature and test it locally on your computer and you also deploy it to a test system to make sure everything works in an environment without your developer tools installed.
Once that’s done, it’s time for the deployment into production. In production all users have access to it.
Let’s say you added search capabilities to your product and now you need to ensure that users can search properly in production.
Most of this you can test beforehand but there’s always a bit of uncertainty around “How does this behave in production?”. This is a very critical point where past projects often took an unexpected turn because the code couldn’t handle the amount of data all at once or there’s some more tweaking required here and there. These are situations you can circumvent with feature flags.
With a feature flag you can decouple deployment from user visibility.
How do you implement a feature flag? Basically, a feature flag is nothing more than a conditional that wraps a specific feature like this:
//render blog posts
feature_flag_active can get the value for the feature flag from a file or database.
The huge advantage here is that you can enable and disable features without redeploying the code. This comes in handy when a component has a critical bug or there are too many users trying it to access it at the same time.
My website 21-lessons.com makes a lot of use of this pattern. Whenever I work on a new feature, on of the first things that I do is to create a new feature flag. I chose to store them in the database so I can enable / disable them through my admin interface.
When I deploy the feature, I usually do the following:
<% if current_admin_user || FeatureFlag.newsletter_enabled %>
<% end %>
To view the newsletter text on the main page the user either needs to be admin or the feature flag needs to be activated. It allows me to test new features in production before everyone can see them. I still test the code on my local machine first, but it gets deployed to production pretty early on so I can test them from the end-users perspective.
How are you testing new features? Are you doing something similar?