Picture this: you are the owner of an e-commerce website, and in the coming month you are planning a grand sale. You have created a wonderful banner ready to be shown on your website, telling your customers about how much they can save.

You only have one challenge left: you need to make this banner visible at midnight, to ensure you don’t lose potential sales. You don’t want to have to deploy your banner to production and have the deployment fail right before your grand sale, but you also don’t want it to be visible to your customers before midnight. So how do you ensure your banner is ready in production, but can’t be seen before the grand sale? Enter Feature Toggling.

This article will cover what Feature Toggles are, why you should consider using Feature Toggling in your applications, common pitfalls when implementing Feature Toggling, existing tools available, and how to get started on implementing Feature Toggling in your application.

What are Feature Toggles?

Feature Toggles (also referred to as Feature Flags, Feature Flippers, Feature Switches, Conditional Switches, and more.) is a way to toggle feature functionality on or off through code.

Depending on whether the Feature Toggle is on or off, two separate paths can be taken through a system. In its simplest form, a Feature Toggle is simply an if-else statement.

if(featureIsEnabled) {
	// Then execute feature logic
} else {
	// Do something else, or nothing at all
}

If the feature is on, the IF part is executed, otherwise the ELSE part is executed.

When incorporating Feature Toggles into an application, there are some concepts you should be aware of:

• Feature flag: The previously mentioned binary state that is either on or off. The state of the feature flag triggers whether the code block runs or not.
• Feature Manager: The feature manager is an application package that handles the lifecycle of all the feature flags in an application. The feature manager often provides more functionality, in the shape of caching feature flags and updating their states.
• Filter: A filter is a rule used when evaluating the state of a feature flag. This could be a user group, a device or browser type, a geographic location, a time window etc..
• Feature Repository: A place to store the feature flags and their current states.

A Feature Repository contains the list of available Feature Flags and their respective states. In this example three features are available, where 2 are toggled ON, and a single OFF. The Feature manager loads in the state of the Feature Flags and makes them available for the application.

Why you should consider using Feature Toggling

There are several benefits to gain from using Feature Toggling. An immediate benefit is the enabling of continuous integration by checking new code into the shared codebase for a feature that is not yet ready. The feature release and code deployment is decoupled, making it easier to control when the feature is made available without requiring a new release. This also makes it an enabler continuous delivery / continuous deployment.

On a business impact scale they allow for feature experimentation, combined with end user feedback, feature toggling enables a company to do things such as A/B testing, where the end users are distributed into two groups, each seeing a different variant of the feature. Whichever variant gains most traffic is then chosen as the default.

A/B testing using Feature Flags. Here two user groups, A and B, are accessing the same menu feature. However, group A will see the menu anchored on the right, while group B will see the menu at the top.

Speaking of releasing to end users, Feature Toggling also enables progressive rollout. The feature can be gradually rolled out to specific user segments, allowing for a more controlled testing and monitoring of the impact of it.

Finally, Feature Toggling also helps when a feature containing a critical bug has been released to end users. Here Feature Toggling allows for risk mitigation associated with new features or changes by easily turning them off in case of unexpected issues.

Common pitfalls when using Feature Toggling

While Feature Toggling provides an abundance of benefits, there are also some pitfalls to watch out for. Here we’ll cover two of the biggest ones: not managing the lifecycle of Feature Flags, and repurposing feature flags.

Not managing the lifecycle of Feature Flags can quickly become an issue. If you haven’t set an expiration date for when you remove the Feature Flag, you can risk ending with a continuously growing list of Feature Flags available. With the lack of housekeeping, your application becomes increasingly more complex to navigate. Every time you add a Feature Flag, the technical debt increases as well as the cyclomatic complexity. Higher cyclomatic complexity requires a higher testing degree, as your application can now take multiple paths through its codebase.

Therefore, remember to manage the lifecycle of Feature Flags, when adding them, plan for its removal as well.

When you’re not managing the lifecycle of your Feature Flags, you also run the risk of not removing them all properly. This issue gets even more troublesome if you decide to repurpose your feature flags.

Feature flags are typically implemented with specific conditions and behaviors in mind. Repurposing them may introduce unintended side effects or unexpected behaviour, especially if the original flag was designed with certain assumptions about the feature it controls.

On a collaborative level, repurposing feature flags can lead to confusion among team members. The original purpose of a feature flag is often documented and understood within the team. Repurposing it without clear communication can lead to misinterpretation and misunderstandings.

What tools are available for Feature Toggling

There are several tools available at your disposal to implement Feature Toggling. This section will cover three available Feature Repositories and a Feature Manager. The Feature Repositories range from using a simple database, to using third party solutions such as LaunchDarkly and Split. Lastly we’ll cover OpenFeature, an open specification aiming to provide a vendor-agnostic feature manager.

Database

The simplest implementation of Feature Toggling is by using a database as a Feature Repository, where a table contains the Feature Flag states. A table can be specified for each environment in use, restricting access to only relevant clients. The following shows an example of a table for a Dev environment

Example of a database table containing a list Feature Flag states and a Feature Manager fetching these states to be used in the application.

The database approach is simple and can be a quick way to detach your Feature Flag states from the Application logic. However, it also comes with all the maintenance a self-implemented solution carries. This means governance, auditing, security, as well as feature flag complexity to name a few, is something that you yourself will have to implement and maintain.

LaunchDarkly

LaunchDarkly is a SaaS (Software As A Service) product, focusing on experimentation and Feature Flags. It supports both simple and complex Feature Flags, and comes with its own SDK that can easily be integrated into the Application. The SDK stores the Feature Flag states in case connection to LaunchDarkly is lost.

Feature Flags are easily created, and a simple overview is available containing the individual features which can be toggled On/Off.

Overview of Feature flags for a Production environment in LaunchDarkly.

LaunchDarkly makes it easy to navigate between the different environments, accessable through their online user interface to ensure you only get the context of the current environment. For governance, environments can also be separated onto different Projects, enabling access restrictions at both a Project and Environment level.

LaunchDarkly has a separation of Projects, where each Project can have several Environments.

LaunchDarkly gives a lot of functionality out of the box, to name a few:

• Approval requests for state change - It is possible to set restrictions on who is allowed to enable / disable a Feature for a given environment. A user can request a change to a Feature Flag change, and an administrator can approve the request.
• Audit Log - All changes to Feature Flags are logged to an Audit Log, enabling change tracking and a historical record containing information about who made changes to what.
• Experiments - Enable easy A/B/n testing variants to quickly test feature variants. Metrics are tracked and made available to drive product experimentation and find experiment winners.
• Feature Flag interdependencies - Easy mark a Feature Flag dependant upon another Feature Flag to ensure it only gets activated in the right situations.

There are three types of licenses available for LaunchDarkly: Starter, Pro, and Enterprise. It is possible to choose to be billed either monthly or anually. The following table shows the pricing for Starter and Pro billed monthly. The Enterprise license is not listed as it requires getting a quote.

Split

Split is another Feature Flag Repository provider, sold as a SaaS product and with a focus on intelligent feature management and experimentation. Split puts an emphasis on privacy and security. This is realised by having the in-app SDK cache the feature flag rules locally to prevent sending of sensitive information to the Feature Flag server.

Split boasts a rich set of features, such as complex Feature Flags, Targeting Rules, Automated Rollout Monitoring, Rollout Dashboards, and much more.

Creating new Feature Flags are intuitive, and can easily be accessed on a per-environment basis, or through the complete list of Feature Flags.

Example of Feature Flag overview for an environment named “Staging-Default” in Split.

The licensing structure for Split differs a bit from DarkLaunchy. Split has 4 tiers, Developer, Team, Business, and Enterprise. The Developer tier is free for up to 10 seats, and the remaining licenses are billed on an annually basis. The Enterprise tier is not listed as it requires getting a quote.

OpenFeature

While LaunchDarkly and Split concorns itself with the Feature Flag Repository part, OpenFeature’s purpose is to simplify the FeatureManager role. OpenFeature is an open source Cloud Native Computing Foundation (CNCF) incubating project under the Apache 2 license. It features the OpenFeature SDK, which provides a consistent way to access Feature Flags, by plugging into various 3rd-party feature flagging providers. The following shows an example where the OpenFeature SDK is using a Flags-R-us Feature Flag Repository service.

The OpenFeature SDK is built with several providers in mind. The SDK attaches to a specific OpenFeature Provider, which then handles API calls to the given Providers service. https://openfeature.dev/docs/reference/intro

The OpenFeature SDK is available in a range of technologies, with examples such as .NET, Java, Node.js, Go, and more.

For each technology, different providers are made available. Taking the .NET OpenFeature SDK as an example, some of the available providers are LaunchDarkly, Split, flagd, and DevCycle.

Getting started with Feature Toggling

In this article we have covered the whats and whys of Feature Toggling. The next step is then to get started using Feature Toggling. Lets take a look at how that can be achieved.

First define relevant use cases. Like all good things, implementation should be done in increments. Identify scenarios where Feature Toggling can be beneficial. This could be use cases where A/B testing is relevant, gradual rollout, or a use case where management of configuration changes are needed.

Once you have defined a set of relevant use cases that would be suitable Feature Toggling candidates, it is time to select a feature toggling system. Choose one that meets your requirements. If you don’t already have a list, consider things such as

• Do we want to buy an existing product or build it ourselves?
• How does it fit into our technology stack?
• What should our governance be regarding toggling Feature Flag states?

When you have chosen a Feature toggling system, it is then time to implement the feature flags in the application. Centralise the fetching of feature flags in a Feature Manager. Once added, document your feature flags. This is a critical step, as lack of documentation of feature flags can risk creating confusion around the usage of a feature flag (an example could be a poorly named feature flag with no documentation).

As mentioned earlier in this article, adding a feature flag adds code complexity. Feature flags add a new way the application can take through its codebase, and this therefore requires more tests. You should test both the inactive and active state of a feature flag.

Finally, once the Feature Flag has served its purpose and has reached its end of its lifecycle, either through experimentation or a time-boxed event, remember to remove it again.