What is Feature Toggle?

Introduction

Feature toggle is a mechanism to enable/disable parts of an application via configuration/ Compile time/Centralized configuration (like settings stored in a database). Not just enabling/disabling the UI elements, but also business functionalities can be enabled/disabled.

Background

Usually, we can achieve the toggling feature via app.config file or other XML files. So what is the difference between handling via config file and using the preexisting libraries (NFeature, FeatureToggle, FeatureSwitcher and nToggle)? I will mainly be concentrating on NFeature in this tip.

In general, a new setting has to be added to the app.config file like below:

<appSettings>

    <add key="OutboundSwitchOn" value="True"/>

</appSettings>

And then in the code, check the config value to enable the feature:

if (bool.Parse(ConfigurationManager.AppSettings["OutboundSwitchOn"]))
{

}

Ideally, this check should be made more robust by using preexisting libraries. The problem with the traditional way is that it’s a magic string. We only have switch for turning a feature on or off. To enable/disable features more dynamically (for example, to enable a feature on a particular date or date range or particular days), custom logic needs to written to handle this.

Apart from switching off and on a business functionality/UI functionality, we can use feature toggle for handling continuous release without branching. Let’s see how to achieve this with an example.

Using the Code

In the above diagram, we have Release A and Release B. If it so happens that the development of some features for Release B is to be started even before Release A is deployed, the usual way to go about achieving this is to create a branch out of the trunk where the code changes for the functionality for Release B is done and once Release A is deployed, the branch code is merged back to the trunk before Release B is deployed. So what is the problem here?

The problems are primarily branching and merging which entails maintaining the code in two different places, testing effort. To circumvent this hazzle, feature toggle can be used.

In the application we’re working on, one particular feature needed to be switched off for a customer. The initial idea to handle this was to branch out, but this approach poses problems as the number of customers increases. Using feature toggle was agreed upon as one of the best possible solutions. Four feature toggle libraries, popular in the market, were compared and one (NFeature) was decided to be the most compatible for any kind of requirements.

Let’s see an example illustrating how Nfeature can be used.

Nfeature requires an enum to be created which defines all the feature toggles. It then generates extension methods using which the config settings for a feature can be checked. Features are configured through a custom section in the .config file. Features can be configured optionally depending on other features and being available for a particular time set (using this, a feature can be enabled/disabled on a particular day or a date range).

Following is a sample of the configuration section:

<configSections>
    <section name="features" type="NFeature.Configuration.FeatureConfigurationSection`1
	[[NFeatureTest2.Feature, NFeatureTest2]], NFeature.Configuration"/>
</configSections>

<features>
    <add name="OutboundFeature" state="Enabled" />
    <add name="InboundFeature" state="Enabled" />
    <add name="ReleaseFeature" state="Disabled" startDtg="23/03/2013:18:00:01"    
			endDtg="23/03/2013:18:00:01" />
</features>

Once configuration section has been done, an enum has to be created for the same. The enum can be configured in the following manner (all the features should be added in the enum so that we can consume in our code.)

public enum Feature
{
    OutboundFeature,
    InboundFeature,
    ReleaseFeature
}

So that covers it all. The NFeature settings have been set up, isn’t it cool? :-)

Now it’s time to use this in the code.

NFeature settings set up so far can be used in the following way:

if (Feature.OutboundFeature.IsAvailable(featureManifest ) )
{
    //do your business logic here
}

IsAvailable method expects object of type IFeatureManifest.

Using Nfeature, the problem of Magic String (we have not accessed directly app.cofig file for checking the condition) and the problem of branching and merging have been bypassed.

If you have any suggestions or queries, please post them. I would be most happy to discuss on those points.

History

• 13^th November, 2015: Initial version