If you’re new to feature flags, then you might be exploring what they can do for you. The good news is that you’re in the right place.
Feature flags offer a lot of possibilities to help you accomplish your various business objectives. In this blog, we’ll discuss some common, and beneficial, use cases for feature flags. Before we dive into the use cases, let’s take a quick look at how we define feature flags.
Feature flags are known by many names. They’re called feature toggles, feature flips, conditional features, feature switches, and splits. Of course, we’re partial to splits.
Feature flags provide a way to maintain control over a release. They also help you ensure code quality during deployment. Before feature flags, you would need to deploy new code anytime you wanted to release a new or updated feature. With feature flags, this process is less complicated. New features or functionalities can be released without new code.
1. Separating Deploy from Release
By deployment, I’m referring to a new version of code that is pushed to your production servers. Meanwhile, by release, I’m referring to when customers experience new features or functionalities.
Without feature flags, these two are done at the same time. When new code is released to the servers, anyone using those servers will get the new features. The problem is that both deploying and releasing are risky. When you leave them together, it’s both more likely that a problem will occur. As a result, this will make it harder to identify what that problem is.
The only way to fix the problem is to roll back the entire release. This can affect many features, not just the one that caused the problem. Rolling back can also be slow and difficult to execute correctly.
Feature flags solve several of these problems. First, they allow us to push new code without users seeing any change in functionality. When we later turn them on, then they will get the new experience.
By separating the two, we make it easier to identify a problem. We can tell if it was a deployment issue or a problem with the release of a particular feature. If the problem is with a new feature, we can easily turn that feature back off using the feature flag.
2. Production Testing
More than an on/off switch for releasing features, you can also use feature flags to target users.
For example, let’s say you want to release a feature for users in Boston or a random percentage of users. You can also turn a feature flag on for all users in the QA group. Or you can target individual, specific users, which can be beneficial to testing. Additionally, a development team can be the first to test new features in a production environment.
Testing new features with feature flags in a production environment will provide a safe space to learn and make decisions. This way, you can get a similar experience to your customers.
3. A/B/C Testing, a.k.a. Experimentation
It can be easy to think about A/B/C testing or experimentation as off-topic for this discussion. But many feature flag frameworks, including Split, collect metrics. These metrics can be tied to the options users experienced for each feature flag. This allows us to track which feature performed best.
Which would you prefer: opinions or data? With feature flags, your decisions can be based on data. You can measure the business impact of every feature, collecting valuable performance, behavioral, and business data. You can ensure that the features you spend time on are the ones that drive business value.
4. Custom Packages
While most feature flags are meant to be temporary, custom packages are an example of permanent feature flags. Feature flags give you control over which features a user sees. As a result, you can use feature flags to create package tiers.
For example, you can have a basic free version with a few features. You can also have a paid premium version with more specialized features. Users can be assigned to their package based on what they paid for.
Tying a group of features together with a single feature flag can also be used to create a release candidate. While many other use cases we’ve discussed work towards getting away from them, sometimes release candidates are useful.
For example, maybe you have a customer who wants to do their own testing. They want to test before allowing their employees to see a new feature. In that case, you can create blocks of new features that are hidden from employees. Access can be given to whoever is doing the testing. Once they approve, then you can release that block to everyone.
5. Temporary UI Customization
Temporary UI customization takes advantage of individual targeting. For example, if there’s a giant storm in Boston that’s affecting my service. I can add a custom message to my UI and use the targeting to ensure that only customers in Boston see the message.
In a more permanent form, this is akin to the “message of the day” that users see on login. Not only can you control the contents of the message, but you can isolate users to show messages specific to them. Besides location, you could toggle account status to show basic tier users product tips, or to upgrade to a premium tier.
Users at the premium tier could get a helpful message about recent feature releases instead. The message of the day can be updated from your feature flag console, or automatically by a PATCH request. This means that messages could change daily without any manual intervention, cycling through a series of messages. In this fashion, you could even make your app tell a “joke of the day” using Split.
With feature flags, you can reimagine the software development process and drive business value.
Top comments (0)