TABLE OF CONTENTS
Feature toggles (also known as feature flags) is a software development mechanism that allows teams to turn on or off a feature, remotely without deploying any code. The objective of this mechanism is to essentially decouple feature rollout from code deployment. Hence, allowing developers to release new features and software quickly with less risk.
In simple terms, a feature toggle is a condition that encompasses feature code that can be toggled on or off. It is very commonly known as feature flags, feature switches, or release toggles. It works as a powerful tool to support continuous integration and continuous delivery.
From a technical perspective, a feature toggle is a “decision point” where the application runs the said feature only if certain conditions are met. The feature can be turned on or off remotely from a configuration file or a feature toggle service can be used to manage all the flags set up to reduce complexity.
The feature toggle has the following characteristics:
Feature toggles can be used for A/B testing, canary testing, and continuous deployment. It is designed to support agile development, can be used for market testing and for streamlining operations.
Feature toggles is a conditional statement that follows a code path during the runtime depending on the condition it meets. The purpose of adding feature toggles is to allow developers to remotely control the rollout of a feature at runtime without affecting the code. So the development team can either enable or disable the feature through an external configuration file.
The application during runtime will check the configuration. If the status of the feature toggle is turned on then the system will run the code snippet. If it’s turned off the application will skip the new feature and execute the original feature instead.
A feature toggle, in the code form, can be anything from a simple conditional if statement to a complex decision tree dealing with single or multiple variables. A feature toggle is assigned a unique name or key to describe the use case of the feature.
As mentioned earlier, the application makes a request to an external data source (like a JSON file) or a feature toggle manager service to find out the flag status. Since the use of multiple feature toggles can prove to be difficult to manage, users tend to use feature flag services to manage all the embedded toggles in a central location. These services also provide audit and usage data for the feature which can be used for the purpose of testing.
Additionally, the feature toggles allow deployment teams to release the feature to a segment of their end-users depending on the assigned attributes. So, feature flags can have different statuses depending on the audiences they’re being shown to.
There are different types of feature toggle categories depending on two main parameters - their longevity and how dynamic their function is. There are mainly four types of feature toggles, placed in the ascending order of their longevity in development.
1. Release Toggles
A release toggle is embedded into the codebase that keeps the feature code inactive. So instead of creating a feature branch, the dev team can write a single new feature. Release toggles are temporary elements in a codebase, so their lifecycle is only up to a couple of weeks.
2. Experimental Toggles
These toggles are mainly used for testing purposes. The toggle splits the user base into different segments to expose an isolated segment to the new feature. The usage data for the segmented users are used to infer the effect of the new feature. As it’s only used for testing purposes, the toggles can be removed once the testing is done.
3. Operational Toggles
Operational toggles are comparatively more permanent in some cases. They are used to turn an operation on or off - generally used while coding a new feature. The longevity of the operational toggle can be different for different use cases. They can either be static or dynamic, as the core operational conditions can vary depending on the functions it regulates.
4. Permission Toggles
Permission toggles, as the name suggests, release a feature only to a user who has permission to access them. A simple example is using permission toggles for premium features, making sure only premium users can access them. They are meant to be more permanent and also are more dynamic compare to the other four.
We have briefly touched upon the possible use cases of feature toggles, but let’s dive into specific details about how feature toggles aid certain processes.
1. A/B Testing
An A/B test is a split testing methodology that hosts two versions of a feature. The traffic is segmented into two groups, each shown to a version of the feature. Here a feature toggle can be used such that if the toggle is turned “on” the user segment will view the A version of the feature and if it’s turned “off” the user segment can experience the B version. A/B testing is a popular testing technique in software development that allows to test variations of codes and get a common consensus on how they are received by the users.
2. Canary Deployment
Canary deployment deployment is also a testing method that is a risk-averse way of testing where only the new feature version is released to only a small subset of users. Feature toggles can be used for this deployment method as well. Since the process of canary testing is meant to test bugs in the code, if during testing the dev team encounters any errors they can simply roll back the feature by turning the toggle off. Dev teams can also make use of feature toggles to acquire data and work deriving insights from them.
3. Trunk Based Deployment
Truck Based Deployment is a software development strategy where new code or features is added to the main codebase or ‘trunk’ instead of creating multiple feature branches. Feature toggles can be incorporated in deploying this strategy, as it enables rapid deployment and roll back just by using a toggle switch.
4. Feature Toggle as a ‘Circuit Breaker’
The ON/OFF switch mechanism of a feature toggle can work as a circuit breaker mainly for the purpose of maintainability and recovering from failures. If a feature exhibits major glitches it can simply be turned off breaking its running circuit.