A Guide to Getting Started Quickly With .NET Feature Flags

Written by: Erik Francis

A feature flag isn't a difficult concept to grasp. You just add an "if" instruction to your app and then remove it whenever you think the feature is ready to be used in production. Is that worthy of being called a feature flag? Yep, definitely. In this post, we'll show you how to get started with feature flags as quickly as we can for you to start with a small win right away. But after that, you must search for fundamental understanding. Think of it like music lessons: first we teach you a couple of guitar chords and a strumming pattern so you can play a simple song. Only afterward do we start to teach you about intervals, modes, harmony, and so on. You must walk before you run. And you definitely need to make your first feature flag before getting into full-fledged feature flag management. Let's get to it.

Saying "Hello" to the World

Since I don't know your level of proficiency with .NET, it makes sense to use an easy app as an example so it can be followed by people with various levels of experience. To do that, I'm going to create a simple "Hello World" app. For the tutorial, I'm going to use the community version of Visual Studio 2017. If you don't already have it, download it and install it for free. Let's start by creating a new project. In Visual Studio, click on File -> New -> Project... or use the keyboard shortcut CTRL + SHIFT + N. Then, it's time to choose the type of project. On the left panel, click on ".NET Core" under "Visual C#." After that, choose "Console APP (.NET Core)." Then configure the name and location and hit "OK."

With the solution already created, you should see something like this:

Well, a hello world is exactly what we're after. Let's just add a line to the code so it looks like this:

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Hello World!");
        Console.ReadLine();
    }
}

Now you're ready to see this app running. Hit F5 and, if everything goes well, you should see something like this:

Time for Version 2

That looks nice and all, but here comes the business with...wait for it...a change in the requirements! Yeah, of course, what did you expect? Fortunately, the new requirement looks simple enough. Beyond "Hello World," the app now also should display the current date in the following format:

Today is Saturday, August 10, 2018.

Let's implement this. Go to the code and change it so it looks like this:

static void Main(string[] args)
{
    var formattedDate = DateTime.Now.ToString("D", new System.Globalization.CultureInfo("en-US"));
    var message = $"Hello World! Today is {formattedDate}.";
    Console.WriteLine(message);
    Console.ReadLine();
}

Time to test again. Hit F5 and if everything goes well, you should now see something like this:

I mean, not exactly, since the date will be different, but you've got the idea.

We Have a Feature. Let's Put A Flag on It!

Now we have an improved version of our "Hello World" app. The code was properly reviewed, tested, and documented, and everything seems fine. However, for whatever reason, management has decided that the feature isn't ready yet for production. Despite that, the code for the new feature will end up in production, since there are other features that are production-ready and need to be shipped. It's clear then that we need some way to disable or deactivate our feature before sending it to the customer. Here is where feature flagging comes in handy. Let's edit our code again so it looks like this:

static void Main(string[] args)
{
    var displayDate = true;

    var message = "Hello World!";

    if (displayDate)
    {
        var formattedDate = DateTime.Now.ToString("D", new System.Globalization.CultureInfo("en-US"));
        message += $" Today is {formattedDate}.";
    }

    Console.WriteLine(message);
    Console.ReadLine();
}

Nice! Now you have your first feature flag! Will that be enough though?

Enter Feature Flag Management

You might be wondering why the code above doesn't seem especially sophisticated. Why all of the fuss about feature flagging if all there is to it is decision branching? Or worse yet why all the fuss if we have to alter the application's code in order to change its behavior? You see, this toy example illustrates very well what a feature flag is, but it doesn't go much further than that. It isn't very useful. The really big advantage of having feature flags in place is being able to change the application's behavior without changing the code. In order to activate the feature, we'd have to change the value of "displayDate" to true, and recompile and redeploy the application. Flexibility is limited in this approach. What it lacks is the ability to move the value of the switch outside of the code.

Getting the Configuration out of Code

One of the possible solutions for extracting the configuration from the code is to use a config file. Look at the code below:

static void Main(string[] args)
{
    var message = "Hello World!";

    var fs = new FileSystem();
    CustomConfiguration config = fs.ReadConfig();

    if (config.DisplayDate)
    {
        var formattedDate = DateTime.Now.ToString("D", new System.Globalization.CultureInfo("en-US"));
        message += $" Today is {formattedDate}.";
    }

    Console.WriteLine(message);
    Console.ReadLine();
}

I'm sure you've already spotted some problems with the code above. For instance, it doesn't use the more canonical ways of dealing with configuration files in .NET. Also, the "Main" method just acquired a dependency on the concrete "FileSystem" class. It continues to be a toy example, after all. But since we're talking about moving the configuration out of the code, the example now illustrates a hypothetical way this might happen.

Centrally Managed Feature Flags

Time for a summary. We began by implementing a toy feature flag using a variable. It's pretty useless in practice, but it demonstrates the concept. Then we took it further and moved the configuration to the outside of the code. It's better, but it's not enough yet.  Big companies use feature toggles (that's another name for feature flags) to perform a variety of sophisticated tasks. To compete at that level, you're going to need an approach that's more sophisticated than local files in a folder.

CloudBees Feature Management to the Rescue

You can start out by creating a CloudBees Feature Management account and get started for free. You’ll sign in and create a new app, picking a name and choosing ".NET" as the installation type.

Then click on "Start Installation." On the next screen, you're going to see the installation instructions, which are pretty self-explanatory:

However, I'm still going to walk you through them. You'll start by installing the required NuGet package. Go to Tools -> NuGet Package Manager -> Package Manager Console. With the Console open, copy and paste the following command:

Install-Package rox-server -Version 3.0.0

Hit enter. The installation should be done in a few seconds. After that, you need to require the necessary namespace by copying and pasting the following line at the top of your controller class:

using Io.Rollout.Rox.Server;

Now initiate the SKD on your code by pasting the following line on the main method, replacing "your-key-goes-here" with the SDK key shown in the third text field.

Rox.Setup("your-key-goes-here");

Finally, build and run the application. On the CloudBees Feature Management dashboard, click on "next" and a cheerful success message will greet you like this:

Implementing a Flag With CloudBees Feature Management

We are now properly connected to the feature flag management service. That means we're good to go and can actually implement our feature flag. Let's start that by creating a new class that will hold our flags. Out of sheer lack of creativity, I'm going to call it simply "Flags." And here is its complete source code:

using Io.Rollout.Rox.Core.Entities;
using Io.Rollout.Rox.Server.Flags;

namespace FeatureFlagDemo
{
    public class Flags : IRoxContainer
    {
        public RoxFlag displayDate = new RoxFlag();
    }
}

More work to do. Let's create an instance of Flags, register it, and use it to check the actual value of our flag. Edit the code in "Main" so it looks like the following:

Flags flags = new Flags();
Rox.Register("flags", flags);
Rox.Setup("5b6d03ff271c8622522b24ce").Wait();
var message = "Hello World!";

if (flags.displayDate.IsEnabled())
{
    var formattedDate = DateTime.Now.ToString("D", new System.Globalization.CultureInfo("en-US"));
    message += $" Today is {formattedDate}.";
}

Console.WriteLine(message);
Console.ReadLine();

Build and run the application again. Then go to the CloudBees Feature Management dashboard. Notice something different?

Yep, that's right. Just by running the code, you've created a new feature flag on the server. Pretty cool, huh? You're not done yet, though. For the flag to actually do anything, you need to add it to an experiment. Looking at the screenshot above, click on “Production,” then click "experiments". This will bring up a screen with a “Create Experiment” button.  After clicking that, you'll be prompted with this:

Now select the flag to add to the experiment. It shouldn't be hard, since you'll only have one by this time. Then click on "Set Audience". This will take you to a new screen:

This screen allows you to fine-tune the details of your experiment. Don't do anything here yet, though. Instead, go back to the application and run it again. At this point, you may be disappointed. It will seem to have no effect whatsoever on the behavior of the application! Why is that? Well, as you can see from the image above, we configured the experiment so that 100% of its audience ("AllUsers") receives the value False. To see the flag really affecting the code base, change the value after "then" to "True". Then click on "Update Audience". Finally, go to the app, build it and run it again and...voilá!

Now, are you in for a little bit of fun? If that's the case, then instead of true or false, choose "Split". Then configure the values for true and false to somewhere between 0% and 100% and have some fun trying to guess what message will be printed. You might call this "Schrödinger's flag", what do you think? Jokes apart, it's important that you appreciate the power something like this puts in hands. You now have a setup that you can use to accomplish real change in your applications without really touching any code. That way, it becomes easy to deactivate and reactive features in order to implement continuous delivery and even full-fledged continuous deployment

. You can also run tests to decide between two versions of the same feature, each one running on a different sample of your customers. Which one leads to more purchases? Which one is safer? Has better performance? Feature flag management can help you answer those and many more questions.

Back to You

The CloudBees Feature Management documentation can provide you with a lot more information about feature flagging, and I advise you to use it. There is a lot you can do with toggles that can't be covered even with a 12-post series, let alone one single post. It’s not the 1990s anymore. We live in a time in which your customers expect the best. Primitive custom approaches aren't enough anymore. Sophisticated feature flag management is a powerful tool at your disposal. You must controller it and put it to use ASAP.

Stay up to date

We'll never share your email address and you can opt out at any time, we promise.