Anyone who has ever released software to customers before I’m sure has suffered from the stress and anxiety it can cause when you’re hoping and praying everything will work just as it did during testing once it’s in production. If this sounds familiar, then I’m happy you are reading this as I’m going to share with you how to remove that pain completely and best of all it’s not complicated or difficult. The answer is Feature Flags. What is a feature flag? In a nutshell a feature flag can simply be thought of as an `if` statement which is wrapped around your new feature code. If the flag is set on then execute the new code (read as enable the feature), otherwise don’t. It really is that simple! The thing is once you start using feature flags, you’ll soon find you want to be able to control them in a more fine-grained way than simply having them on or off. How to get started using feature flags? There are basically 3 ways to get up and running with feature flags: Create your own feature flag management solution Use an open-source project Use a third party vendor who provides feature-flags-as-a-service In this post I will share with you about using feature-flags-as-a-service and how you can leverage on the provider to get feature flags integrated into your development process quickly while at the same time getting the find-grained control over each of your flags. The feature-flag-as-a-service provider we will be using today is Floodgate . Floodgate provides as out-of-the-box feature flag solution which you can integrate into your code without fuss and instantly be reducing your software release risk. Time for some full disclosure! My name is Eugene and I am the founder of Floodgate. That being said, the advice I am giving is relevant when implementing feature flags in any of the ways mentioned above. Using feature flags in general will give you great benefit in reducing risks during software release. Getting started I will demonstrate a very simple feature flag implementation in which we are going to be launching a new “recommended purchases” widget on an eCommerce website called Acme Online Store. Usually when we deploy code the feature would be on immediately for all customers. Now we will add a feature flag to control who will see the recommended purchases widget and when. We will first need to sign up to Floodgate and get a free account. Within Floodgate we will need to create an Application along with an Environment. You can think of an Application as your project and an Environment as the different environments your code passes through during the development life-cycle. Environments are beyond the scope of this article so for now we will create a new Application called “Acme Online Store” with a single Environment called “Production”. Once created you will see your new application and environment. I’d like to bring your attention to the long random string shown above called the SDK Key, this is the unique identifier for your environment, and you will use this later when configuring the SDK in your application. Once we have our application and environment created, we can create the feature flag we will use to control the new recommended purchases widget. Create a new flag and give it the name of Recommended Purchases Widget, you can leave the default created Flag Key. The Flag Key is a unique identifier for the flag which we will use in our code to check if the flag is on or off. We will leave the Flag Type as Boolean and set the default value to false. Excellent, we now have an Application, Environment and Flag created. Lets head on over to our project and add the feature flag into our code. We need download and install one of Floodgates SDKs for our language of choice into the project, this is done via your solutions package manager such as NuGet, npm etc… Once installed we need to tell the SDK where to get our feature flag data from. We do this by setting the Environment SDK Key we saw on the environment screen above. FloodGateClient floodgateClient = FloodGateClient( ); new "b41411b56d23f03bbdd976419bfa05eb70f21eee074b4acb4d239b8cef32" Below is a simple code snippet showing the feature flag in action within our code. customAttributes = Dictionary< , >() { { , }, { , } }; User user = User( ) { Email = , CustomAttributes = customAttributes }; show = floodgateClient.GetValue( , , user); (show) { } var new string string "Plan" "Gold" "CountryCode" "UK" new "a-unique-id" "customer@doamin.com" var "recommended-purchases-widget" false if // Show Recommended Purchases widget There are 2 parts I want to bring to your attention within the above code. We are creating a user object in which we are assigning the custom attributes of `Plan` and `CountryCode` to. You can assign as many attributes as you want to a user. We will use these later in the Floodgate interface. You can see that there is nothing special to the feature flag statement, it’s just a simple `if` statement. The second parameter of `false` is called the default value, it means if there is any issue when trying to evaluate a flag this is the value which will be returned. This way you can always write your code covering all eventualities. Adding a feature flag inside your code is straight forward. Now let’s head back over to Floodgate, this is where the magic really happens! How does using feature flags reduce my software release risk? I am sure you have guessed by now that with a feature flag inside our code we can deploy that code without showing (releasing) the feature. We have the ability to turn the recommended purchases widget on and off via the Floodgate interface without having to deploy our application again. However even though we can now turn the recommended purchases widget on and off easily we still have a high risk because it’s either on or off for all customers in one go. This is still not ideal because if there is an issue that issue will affect everyone. One of the most powerful functions of a feature flag solution is the ability to have a single flag be on or off for different users at the same time. We can achieve this in Floodgate in one of two ways, with percentage rollouts and with user targeting. This is where using an off-the-shelf solution really shines because you will have these abilities right out of the box. Percentage Rollout Floodgate allows you to set a flag to have different states depending on a percentage of the users on your application. In the example shown below I’m setting the recommended purchases widget to be shown to 10% of the users who visit the website and the other 90% will not see it. This allows me to easily test the recommended purchases widget with a random 10% of my user base. If everything is working as expected I can slowly increase the percentage of users who will see the widget. Doing this I can gradually see how my application responds to the new feature. If there is any issue detected I can turn it off at the click of a button. User Targeting We can use user targeting to achieve very fine-grained control over who will see the new recommended purchases widget. User targeting makes use of the attributes we set in the code example at the start, we can use these attributes to control who will see what and when. Below I have set the recommended purchases widget to be shown for only customers in the UK by using the attribute of CountryCode. With user targeting you can create multiple rules which allows you to target very specific subsets of users as needed. So long as you have the relevant user data and set it as a Floodgate user attribute, you can use it to target flags towards those users. Below is a quick example showing a more complex targeting strategy where I have targeted users who subscribe to a Gold or Silver plan and are from the UK or have an email address ending in @floodgate.io. You can add multiple rules to a single target and multiple targets to a flag. Wrapping things up By using feature flags, you have absolute control over who sees your new features, who doesn’t and when and you can control all of this without redeploying your code. By turning on your new feature to only a small percentage or small targeted user base you can . greatly reduce the risk of your feature releases If your feature is not working as expected, then you know that it’s only affected a small set of customers and not your entire customer base. You can easily turn off the feature if you find it’s misbehaving and not performing as expected. As you can see once you start to understand and using feature flags there is a lot more going on behind the scenes that you may first realize. Therefore, it’s a good idea to invest in using a feature-flag-as-a-service solution like Floodgate rather that investing the time and effort it takes to develop a feature flag solution in-house. Just like you would outsource complex activities such as payment processing for example, it makes sense to extend the same philosophy to your development and deployment tools to - this allows you to focus on your core business which is what should be most important. Happy flagging! Eugene
