Decoupling releases from deploys using feature flags

So you've been working on this new amazing feature for a while now. You're ready to click the merge button and deploy to production, but your product owner is holding you back because there are still some minor design tweaks or not everything was translated yet.

Your branch is getting outdated because other team members are fixing bugs and releasing other features in the meanwhile. You're spending more time fixing merge conflicts than actually working on your new feature.

Sounds familiar? Time to decouple your deploys from releases!

At Teamleader, the company I'm currently working at, we deploy as much as up to 20 times a day. No way this would be possible using a standard git-flow with a master, develop and integration branches. How did we do it? Feature flags (also known as feature toggles).

Feature flags are a software development technique that turns certain functionality on and off, without deploying new code. This allows for better control and more experimentation over the full lifecycle of features.

From a code perspective it looks something like this:

if (isFeatureEnabled("your.flag.key", $user)) {
  # application code to show the feature
} else {
  # the code to run if the feature is off
}

Feature flags come with a bunch of interesting benefits (depending on which functionality your implementation offers):

Gather feedback faster

Once a new feature is deployed behind a feature flag, the product owner or whoever is in control of new features can decide to release the feature to a select number of users or a beta audience.

This allows you to early gather feedback during the development of a feature and work in a truly agile way.

Release features when you want

Put your product owner in control of new releases. Once he thinks everything's ready to release he can do so independently of the development team.

Emergency kill switches

When a bug is discovered, the product owner can easily disable the feature without an entire code revert/rollback. Rollbacks are now basically instantly!

Gradual rollouts

Some feature flag systems offer the ability to gradually deploy a feature over time based on specific user properties such as language, country, age. This allows you to safely monitor if your feature is introducing bugs or causing a performance hit on your infrastructure.

Test in production

Real men test in production right? If you're not sure about a certain bug fix or change in behaviour you can put the new code behind a feature flag, enable it for a specific customer or set of users and see if it actually fixes the issue or makes it worse. Remember, reverting is as easy as disabling the feature flag!

Deploy more often

Now that the release of your feature is controlled by a feature flag there's no need for those huge integration branches anymore. Merge small incremental pull requests straight onto master and deploy more frequently. The more you deploy, the smaller the code change and the quicker you will be able to identify what code change introduced a bug.

---

While feature flags introduce many awesome benefits, they do introduce a slight overhead in maintenance. Once a feature is fully rolled out you should remove the feature flag from your code base. Otherwise, you end up maintaining too many code variations.

There are quite some online feature flag tools out there. At Teamleader we use LaunchDarkly. I'm not really aware of any open source alternatives so feel free to drop suggestions in the comments!