A feature toggle or ‘Feature Flag’ is a technique in software development that attempts to provide an alternative to maintaining multiple branches in source code, such that a software feature can be tested even before it is completed and ready for release. Feature toggle is used to hide, enable or disable the feature during runtime.
In its simplest form, a feature flag is an if/then statement that says if the flag is OFF, use the old feature, and if the flag is ON, use the new feature. You might think, ‘Can't I just have a module or plugin that I turn on and off?’ This is a common approach, but feature flags allow for more nuance. Feature flags are intended to cover multiple scenarios:
Where feature flags become even more interesting is that they serve both product management and engineering. For product managers, feature flags give them the ability to turn features on and off for different types of customers and allows them to roll that feature out to certain percentages of users. But on the engineering side, where it really helps is more and more companies are getting into microservices where dependency management can be a challenge.
If you’re developing large-scale projects without feature flags, you should be thoughtful about your dependency management strategy. Let’s say you’re deploying and you need to create a feature. To create this feature, you need to implement something in these eight different services. Imagine you are working on a feature that adds functionality to a backend service that can't be used downstream until the dependent services are ready for it. The code can be pushed to the backend service and deployed to production with the feature flag disabled.
Once all the pieces are deployed with the flag off, you can allow product management to enable it as they see fit.
With a well-built suite of unit, integration, and end-to-end tests (I know e2e testing is a debate all of its own that we won't discuss here), it's safe to push to production because the tests are checking both of the flag states. In this scenario, you're still responsible for fixing any failed builds, but there's no merging, and no merge conflicts. You're constantly deploying because everything is a flag and there are companies that will run with hundreds or thousands of feature flags at a time.
There are a few ways to implement feature flags. You could roll your own system, subscribe to a commercial SaaS platform, or you can deploy an open source one.
The available commercial feature flag platforms are easy to get started with. There are very robust SaaS products such as LaunchDarkly and Optimizely that target larger organizations, but as we like to bring enterprise features to projects of any budget, we have also tried less expensive solutions such as Bullet Train and CloudBees.
Generally, feature flags are implemented in two parts:
One point of clarification is that feature flags are different from multivariate testing. Frameworks such as Monetate, Optimizely Web, and Google Optimize are that they're focused on marketing optimization, whereas feature flags focus on entire features from both frontend and backend perspectives.
A great resource is FeatureFlags.io from LaunchDarkly. They cover everything from introduction, getting started, use cases, best practices, and how it all ties in. They even discuss third-party services and libraries.
Let's say you're building an internal company portal, and you're fetching the weather. You have three main parts to this:
Note: Let's assume the "backend" is a monolith. This is fairly common, and there are many other considerations with microservices that aren't suited for a quick example.
You want to move to a new weather API, but you don't know how accurate it will be when running in a real-world application.
You take the following steps:
There are two main groups who benefit from feature flags -- engineering and product management.
Within our client base, product managers are the ones turning this on and off and choosing the merchants in production environments. Product managers can choose, based on their conversations with business, how to roll a feature out and who to roll it out to.
For example, they say, `One of our users had issues with this feature. Let's turn it off for them, check the logs, talk to them, and address the issue.’ A few minutes later, the flag is disabled in real-time. This helps engineers because they are able to focus on the tasks at hand and not worry about having to roll back.
The engineering team can deploy code as it's ready across numerous services without wasting time on merge conflicts. While a normal and expected, reducing unnecessary merge conflicts can save a lot of time, especially when we're pushing hundreds of commits per day.
It gives the people who are the most in touch with customers, such as product managers, more control over the customer's experience. Now, the customer is defined differently from business to business and in the case of product managers we tend to consider a multi-tenant SaaS product.
But product managers are much closer to the actual customers than the engineers. And so the product managers are the ones doing customer interviews, asking what features they'd like, or they don't like and figuring out what the engineers should be building. So really putting it in their hands really just gives them that control and that’s a big benefit.
The developer part of me says there's no reason not to, but realistically, if it introduces a risk or overhead that you're not prepared for, then it's okay not to do it because you can build a control panel into your app.
For example, common open source platforms such as Drupal, Magento, and WordPress utilize plugins or modules. If you're not building your own platform, you'll probably see less benefit because platforms will often have mechanisms to handle the ability to enable or disable features.
If you’d like to learn more about Feature Flags, or how SUMO Heavy can help your organization, set up an Office Hours or reach out at firstname.lastname@example.org.
If you’d like to learn more about SUMO Heavy, drop us a line, give us a call or contact us on social media.