If you haven’t tried feature toggles, they may seem daunting and/or abstract at first. But they can be implemented in a very simple way and will provide you with a powerful mechanism to change your code. Once you get to know feature toggles, you won’t ever want to write code without it anymore. And once you’ve implemented it yourself a few times, you’ll want to look at elaborate solutions.

Simplifying things more than a bit, feature toggles allow you to switch a new feature on or off at run-time. Instead of deploying feature B to replace feature A, you deploy both. Then, at the flick of a switch, you activate feature B and deactivate feature A. The nice thing is that this provides safety to switch back to feature A in case things go wrong. No need for a new deployment.

Configuration

The fastest way to set up a feature toggle seems to be working with your environment’s configuration.

For classic .NET applications, this would mean adding aan appSetting:

<appSettings>
    <add key="UseNewPriceCalculation" value="true"/>
</appSettings>

In the above example, you could easily check the value and go from there:

if (ConfigurationManager.AppSettings["UseNewPriceCalculation"] == "true")
{
    return new PriceCalculator().CalculatePrice(input1, input2);
}
else
{
    return new LegacyPriceCalculator().CalculatePrice(input1, input2)
}

The above code has lots of ways it could be improved, but you should get the general idea.

The same can be done with the new configuration system in .NET Core.

Storing Values Across Releases

As I said, the above code could be improved. You might want to use a class that abstracts away the logic to retrieve the feature toggle values. You could use enums instead of magic strings. You could also add a UI that allows a user or admin to easily change the value.

But one specific downside of working with configuration files, is that they will be overwritten with the next release.

That is why I’ve set up a system similar to the one explained below. The idea is to have a fixed set of features which can be toggled in a UI. The value of the toggle will then be upserted in the database.

First, I have a list of features:

public enum Feature
{
    NewPriceCalculation,    RedisCaching
}

This is a hard-coded list of features I want to switch on or off. If a feature toggle is no longer due to change, I will remove the corresponding enum value.

To store the value of the toggle in the database, I use the following class, which maps directly to a table in the database:

public class FeatureToggle
{
    public int Id { get; set; }
    public string Feature { get; set; }
    public bool IsEnabled { get; set; }
}

Creating a UI to manage your feature toggles is then as simples as:

• listing all Feature values
• adding a checkbox per Feature, with the checked value of the checkbox equal to the IsEnabled value of the corresponding FeatureToggle

When the user changes anything and saves the values, I

• TRUNCATE the FeatureToggle table in the database
• add a row for every Feature
• set the IsEnabled column to whatever the user selected

This ensures that, when the user changes anything, my database table is cleared from any features that no longer exist.

Assuming an ORM like Entity Framework, checking for a feature toggle is then as simple as:

if (MyDbContext.FeatureToggles.SingleOrDefault(x => x.Feature == Feature.NewPriceCalculation.ToString())?.IsEnabled)
{
}

This provides persistence, auto-cleanup and compile-time safety (no magic strings).

But it has its limitations.

For example, I only allow for boolean values in my feature toggles. If I want multiple values, I need to fall back to strings in the database, forcing me to use strings in my code too, i.e.:

if (MyDbContext.FeatureToggles.SingleOrDefault(x => x.Feature == Feature.Caching.ToString())?.Value == "Redis")
{
}

Not such a nice solution. But why are we reinventing the wheel here?

Focus On Business Value

Take a step back and ask yourself if you would write your own database. Or dependency injection framework. Or logging solution. And so on. Why should we be writing our own feature flag solution? Our problem isn’t special, so maybe we should be focussing on the business domain of our application.

Investigate the list of feature toggle libraries for your technology at featureflags.io. You’ll probably find something that does what you want, and more.

This is also where a solution like Rollout can help out. If all you need is a feature flag now and then, you could start with your own solution. But when you need things like authorization, consumer segmentation, gradual rollouts, auditing, analytics, etc. you shouldn’t be doing this yourself. Not on company time.

Feature flags are powerful and once you’ve used them, you’ll want to use more of them. Then it’s time to start looking at more professional and full-featured solutions.