Feature Flags is useful method to integrate rapidly new functionality, finished or unfinished, into the product. But there are also some traps.
There are different categories of Feature Flags 1:
- Release Flags
Release flags are enabled or disabled by deployment and are typically used for the features which are still in-progress. The longevity of Release Flags should be between days and weeks.
- Experiment Flags
Typically, Experiment Flags are used for A/B tests. They are dynamic and are enabled or disabled for example by http request. The Experiment Flags can live in the code base between weeks and months.
- Ops Flags
Ops Flags can be used by rolling out a new feature which can have a performance implications on existing application. Ops Flags allow to enable or disable the feature by run-time reconfiguration. They can have longevity between months and years.
- Permission Flags
Permission Flags can stay in the code base forever. They are used to enable or disable features for only certain users.
When you create new functionality it is common to create a new branch. This is fine when the new feature is integrated into production code very soon, in the best case next release, like the feature/x in the picture below. But what will happen to the code when the feature/y will not make into the production by next release? The longer it takes to, the higher the risk of merge conflicts. But there is more: costly integration and delayed feedback can rise a risk to deliver poor quality.
With the Feature Flags you can integrate as often as possible, than Feature Flags allows you to deliver also unfinished functionality. This make possible to test the code and the functionality continuously and at very arly stage.Unfortunately the Feature Flags can create some very serious problems if implemented and deployed improperly and have some disadvantages like:
- Temporary code base noise
- Risk of leaky code/feature
- Necessary code changes by removing the flags
- Increasing code, test, integration and operation complexity
Feature Flags with FeatureToggle
This example show how to use Feature Flags with FeatureToggle Framework in the ASP.NET Application. The purpose of the application is to track To-do’s. The design is very simple.
In this example is the value of the Feature Flag persisted in the database table ApplicationFeatureFlags
.
CREATE TABLE [dbo].[ApplicationFeatureFlags] ( [Id] INT IDENTITY (1, 1) NOT NULL, [Name] NVARCHAR (MAX) NOT NULL, [IsEnabled] BIT NOT NULL );
The table contains only singe entity IsCompletedFeatureFlag
.
To get the value of Feature Flag from the database SqlFeatureToggle
class is used. New class which represent the Feature Flag self is created and inherits from the SqlFeatureToggle
class.
namespace ToDoApp.Common.Features { using FeatureToggle; public class IsCompletedFeatureFlag : SqlFeatureToggle { } }
The IsCompletedFeatureFlag
class is used as a property in Todo
model.
namespace ToDoApp.Common.Models { using System.ComponentModel; using System.ComponentModel.DataAnnotations; using Features; using Newtonsoft.Json; [JsonObject] public class Todo { [DefaultValue(false)] [Required] [DisplayName("Completed")] [JsonProperty] public bool IsCompleted { get; set; } [Required] [JsonProperty] public string Description { get; set; } [JsonProperty] public int Id { get; set; } public IsCompletedFeatureFlag CompletedFeature() => new IsCompletedFeatureFlag(); } }
In the Todo\Index.cshtml
view are certain controls rendered only if the CompletedFeature
is enabled.
@if (item.CompletedFeature().FeatureEnabled)
{
}
There is one important thing to do. To be able to SqlFeatureToggle
to get data from the database there is need to have a connection string or connection string name and select statement defined in the web.config.
To be able to manipulate the IsCompletedFeatureFlag
there is also a applicationfeatureflag
REST API Endpoint. Just call /swagger
on API to see all available methods. There is also UI to manipulate the Feature Flag as you can see below.
One notice on the design. You will not probably want to use the FeatureToggle as describe above as this is only very naive implementation to keep the sample easy. Better approach will be to get the flags value over the API. FeatureToggle Framework allow you to implement your own custom logic. There is also great Pluralsight course on FeatureToggle’s.
Sourcecode
Cite Sources
1 Hodgson Pete, “Feature Toggles (aka Feature Flags)”, Martin Fowler (blog), 09. October 2017, https://martinfowler.com/articles/feature-toggles.html