The problem

Where I currently work we use continuous integration. When software is in development this doesn't cause any problems. Just commit, it doesn't matter if you break something or add a new feature. When your software is live, it's a whole different story, everything becomes a bit scarier. Assuming you release fairly regularly, say once a day, new features and other changes must be hidden from the user until they are ready. This is where feature toggles come in. The theory behind feature toggles is very simple, but implementing them in .NET was causing me a headache. I struggled to find any useful information on a practical, tried and tested solution. 

This blog is my attempt to explain the solution me and a couple of colleagues came up with in a fairly short space of time. I'm perfectly happy to say it's not perfect or super elegant, but it works, and it's simple. For a more comprehesive feature toggle solution it could be worth looking at NFeature. It turned up while I was looking for examples of feature toggling in .NET and while I haven't tried it, it looks like a nice solution. At the time I wasn't happy to introduce yet another dependency on a 3rd party piece of software so opted not to use it.

Requirements

Any feature toggling solution we used needed satify a number of requirements. Most importantly the toggles must be accessible in any project within the parent .NET solution and must be configurable for each environment. E.g. On in your testing environment, off in live. In addition I wanted to make it as easy as possible to remove the toggles. That being the case I wanted each toggle to be defined in a single location that when deleted would cause build failures until all references to the toggle were removed. Finally I wanted an implementation where toggles could be used in the view, controller and model and would not break any unit tests.

Implementation

The first step is to create a new web.config file to hold the toggles. Why a seperate file? This way web.configs from each project where the toggles are to be used can refer to this one file. I called my file featureToggles.config. This file can be used to store simple boolean appSettings which define whether the toggle is on or off.

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

When the featureToggle.config file is created, if you're using .NET 4, config transforms will automatically be created for you. They are required for this particular solution. If you're using .NET 3.5 or below you'll have to find another way to handle the transforms, sorry. Add a transform value for each environment. For instance my live transform might look like this:

<appSettings xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
 <add key="MyFeatureToggle" value="false" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>

How are the new appSettings loaded when they aren't included in the web.config file? One of my colleagues helped with that. The file attribute of the appSettings element allows you to specify a file which contains extra appSettings. So for whichever projects in your solution need to use the feature toggle simply add a reference to it in the appSettings element. For example our solution contains two web projects both of which require use of the feature toggles, so their appSettings elements would look something like this:

<appSettings file="featureToggles.config">

<appSettings file="../Web/featureToggles.config">

It's worth noting that if you are automating your builds using something like MSBuild you will need to add an extra step to apply the appropriate transform to the new featureToggles.config. I'm not going to go into the details here but if you want more information this post should help.

The next step is to get the appSettings values out of the config file. To do this I created a static class:

public static class FeatureToggles
{
  public static bool MultipleCards()
  {
     return ConfigurationManager.AppSettings["MyFeatureToggle"] != null 
 && ConfigurationManager.AppSettings["MyFeatureToggle"].ToLower() == "true";
  }
}

This the single place in code where the feature toggle is defined. If you want to remove the feature toggle simply delete the appropriate method from the static class and clean up the build errors. Why a static class? Because it can be used very easily in areas you aren't worried about unit testing. E.g. Views. What about using feature toggles in your model where introducing a static class would break unit tests? For that purpose I created a wrapper round the static class:

public class FeatureToggleService : IFeatureToggleService
{
  public bool MyFeatureToggle()
  {
    return FeatureToggles.MyFeatureToggle();
  }
}

The FeatureToggleService class can be injected into any model class. The return value can be mocked so you can unit test your code with the toggle both on and off. Now it's simply a case of adding feature toggle code when you need hide a feature. For example:

<% if(FeatureToggles.MyFeatureToggle()) { %>
   <%--Link to some awesome new feature--%>
<% } %>

 if(featureToggleService.MyFeatureToggle())
   // New code
else
   // Old code


In summary


Advantages
  • It's simple
  • Toggles can be loaded into multiple projects from one transformed file
  • Existing unit tests are not broken and feature toggle service can be mocked so features can be tested while switched on

Disadvantages
  • Adding a new toggle involves more steps that I would like
  • As far as I'm aware the appSettings file attribute can only contain one value, so if it's used to load feature toggles it can't be used for anything else
  • In a big project the featureToggleService would potentially need to be injected into a large number of classes which I don't like. Do you inject it into all classes, or just the ones you need and then remove it when you're done? Rock. Hard place
  • Toggles must be flipped by manually editing a file