# Feature Flags

.
17
One of the interesting things is separating deployment from release. And a lot of organisations use feature flags to determine whether or not something is visible to a user of their application. What they allow us to do is to take something, push it out to the production environment– in other words, deploy it– but not actually release it to the customer. Let’s take a look with a definition of that. Feature flags are toggles that show or hide features in the UI through some sort of configuration. It’s used if features aren’t done but you want to push them out to production, or if people shouldn’t have access to those features yet. They may be done, but we’re not ready to launch them.
60.3
Also, very helpful for things like A/B testing, or setting up permissions for various user groups, or operational tasks, a whole bunch of other things. In fact, I’ve often seen people use feature flags to identify groups of users who have paid extra for extra features. You can go in and say, I want to pay $5 a month. You get access to this bucket of features. I want to pay$10 a month and get access to a larger bucket of features. So feature flags are also useful for that. Now, there’s a lot of tools that are available for setting feature flags.
95.1
On the .NET framework, there’s things like Launch Darkly, and there’s tools for every framework out there to let you push, into production, features that aren’t yet turned on for your users. So look into feature flags as something that is potential option for you to use in your DevOps pipeline that might allow you to hit a faster cadence and get code out to production, even if it’s tagging along some code that’s not yet ready for users to see.

In this first step of exposure strategies, we will investigate feature flags. A feature flag is a conditional in your code, an if, then for two different options. At its simplest, a feature flag can be used to flag new or risky behaviour. First, the feature is deployed off. Then, separate from deployment, you can turn on the new feature.

If the feature doesn’t behave as expected, it is possible to shut it off quickly. This is better than rolling back an entire version because you have isolated the change. In addition, it allows development on other features to continue without forcing a complete rollback. In effect, you’re isolating the change while your codebase evolves around it. Risk is the uncertainty of unknown issues. With feature flagging, you’re mitigating risk by making every feature encapsulated and controlled.

Feature flags are effective for risk mitigation, fast feedback, hypothesis-driven development, and long-term control. There’s no one right way to use feature flags.

In the following step, we will learn about experimentation.