What is the benefit of using the Azure Feature Manager vs regular configuration value of "true" and "false"

Question

From what I've seen here if I have an Azure App Config set up and want to have a feature flag in it, in order to read its value or take advantage of it I must:

1. Install a nuget, separate from the Microsoft.Extensions.Configuration one I already need for App Config
2. Add "UseFeatureFlags" in "CreateHostBuilder"
3. Register the feature management in startup services
4. Have an enum, designed specifically for each flag
5. Register the feature manager in the "_ViewImports"

And I don't see what benefit ALL THAT gives me over having a standard config value with wither "true" or "false" and skip all the previous steps and just go "if (featureValue)".

So, what is the benefit I am not aware of that is worth going through all that trouble?

Answer 1

The key feature is probably the use of conditional feature flags, https://learn.microsoft.com/en-us/azure/azure-app-configuration/howto-feature-filters-as.net-core , which are considerably more complex than just storing a boolean in your configuration.

Using a library that supports both consistently is then a far better idea.

However, if you're only ever planning to use static feature flags, you may consider it more effort than it's worth.

Answer 2

In short here are some of the pros:

• a centralized location to manage feature flags
• labeling options
• feature filters

A Targeting filter is a built-in filter which allows dynamic enabling or disabling of features for specific users or groups. For example, you can use a targeting filter to enable a feature for only a specific user during a demo. You could also use it to progressively roll out new features to users in custom groups or "rings", or to set a default rollout percentage to release features to all users.

Next to this, feature management helps developers address the following problems:

• Code branch management : Use feature flags to wrap new application functionality currently under development. Such functionality is "hidden" by default. You can safely ship the feature, even though it's unfinished, and it will stay dormant in production. Using this approach, called dark deployment, you can release all your code at the end of each development cycle. You no longer need to maintain code branches across multiple development cycles because a given feature requires more than one cycle to complete.
• Test in production : Use feature flags to grant early access to new functionality in production. For example, you can limit access to team members or to internal beta testers. These users will experience the full-fidelity production experience instead of a simulated or partial experience in a test environment.
• Flighting : Use feature flags to incrementally roll out new functionality to end users. You can target a small percentage of your user population first and increase that percentage gradually over time.
• Instant kill switch : Feature flags provide an inherent safety.net for releasing new functionality. You can turn application features on and off without redeploying any code. If necessary, you can quickly disable a feature without rebuilding and redeploying your application.
• Selective activation : Use feature flags to segment your users and deliver a specific set of features to each group. You may have a feature that works only on a certain web browser. You can define a feature flag so that only users of that browser can see and use the feature. With this approach, you can easily expand the supported browser list later without having to make any code changes.

Source: Feature management overview