What are Feature Flags? Definition, Benefits and Use Cases
Published on Feb 15, 2022
by Simran Arora
Getting your software deployment prepared for targeted functions takes work. But the truth is, you can’t get the features ready to serve even when your deployment is ready. If you’re considering deploying your software for business or other commercial purposes, you must have drafted what features and services you will enable in the deployment.
Sadly, there was no opportunity to try the software deployment features before enabling them in the software applications. This led to improper software functions and features, interrupting the user experience. Moreover, adding a new feature to your software deployment is risky before testing it at least once.
The good news is that the trial option is available nowadays to enable the software deployment features. The practice of utilizing feature flags became a savior for several software applications.
This article clarifies feature flags and tells you whether you should get the most out of them.
What are Feature Flags?
Using feature flags in modern software development allows for decoupling feature deployment from release with a simple on/off toggle. Hence, it is also called feature toggles or feature switches. Feature flagging reduces risk via canary testing, enabling functionality rollout to a limited set of users and measuring the impact those features have via A/B testing. Using feature flags in modern development processes such as CI/CD and DevOps allows for continuous innovation with high velocity.
Feature Flags Explained with an Example
Consider an ice cream boutique opening a new chain in a new area and wants to advertise it on its application and website with a catchy banner; let’s call this opening banner. This advertisement requires it to be visible only to the potential customers living near the area where the new chain will be inaugurated. In this case, we can define feature flags encompassing the feature code so that switching the feature on and off is easy. So, the feature flag pseudo code could be:
if(storeOpen.isEnabled())
{
showOpenBanner();
}
After the code is in production, it will be available to any or all users using feature flags; a dark launch feature will encompass the code. The dark launch feature is when the code is in production but not visible to all users.
We want the advertisement display limited to certain users living near the new chain; the segment concept is used in this case. The segment is a user or a user group with attributes tied to them. In this case, Segment A would have customers having attributes such as common current location and zip code as of the new store.
We must test the feature before making it available for the audience, so in this case, we can define SegmentB, the users with the attribute as their employee email ID. So, we can flip the toggle on for Segment B, and if employees find any issues that need fixing, we can flip the toggle off until the issue is resolved and flip it on again for testing.
Once the employees test the feature and are satisfied, we can effortlessly open it for users of Segment A by shifting the toggle feature to on, as it would require no deployment as the quality is already in production.
Types of Feature Flags
Feature flags are categorized into five types that help manage the feature release in our application. They can also help with A/B testing, beta testing, and development.
Let us see the five types of feature flags below:
1. Release Feature Flags
These flags are used to release the new feature to a specific user or group of users. Developers can use this feature by removing the part to limited users or some users within the company to test the usage and roll it out for everyone after monitoring its impact and being satisfied.
2. Experimentation Flags
As the name suggests, these flags are used for experimenting with a subset of users before publicly releasing the feature. Developers can use experimentation flags to conduct A/B testing and analyze the insights to decide which feature to roll out to get conversions.
3. Operations Flags
These flags are also called ops flags as they are mostly used by Ops and DevOps teams to control the application's behavior in scenarios like load balancing, i.e., if there is too much load on the current server, the user traffic can be redirected, maintenance mode and disaster recovery.
5. Permission Flags
These flags help with providing features to limited users or authorized personnel only. Developers can use this flag in case the feature is sensitive and must be only visible to the required number of users or those authorized.
6. Kill Switch Flags
As the name suggests, it can be used in a security emergency if the application is vulnerable to some threat or critical issues. Developers can use these kill switch flags to lower the impact of threat and prevent users.
Benefits of Feature Flags
1. See off Redeployments Permanently
With feature flags, a particular feature in the source code of a deployment can be toggled on or off in different versions of an application in different environments.
This facility allows testing a new feature in a development environment while having it off in the functional environment. When ready, one can turn the feature on in the functional environment.
This alleviates the hassles of redeployments while saving time and improving users’ experience.
2. Frequent Deployments Increase Revenue
Most development teams test the new changes before deploying the code. Sometimes changes in each deployment to ensure that everything is well-tested before being rolled out to production. This creates the sensation that deploying new code is risky, so development teams avoid frequent deployments. A snowball effect is created, making it even riskier and time-consuming when code deployment happens.
When using feature flags for every code change eliminates such concerns. Software engineers stop being afraid of deploying code because they know nothing will change for their users after the code is live. They don’t even need to know all the code changes rolled out. The flag can be turned on for customers when a feature is ready. The team is responsible for that feature will likely ensure a deployment after the last code change has been committed and will turn on the flag internally to test the feature in production before exposing it to real users.
Engineers or teams deploy their code to production multiple times a day in some organizations when working this way. This decoupling of code deployment and feature rollout decreases the cost of deployments and increases the velocity of software teams. Engineers stop being afraid of deploying code, and deployments increase exponentially.
There’s a big correlation between an organization's revenue and the number and velocity of deployments made by the product teams (see the book ACCELERATE, Building, and Scaling High Performing Technology Organizations).
3. Synchronise Release Cycles with the Marketing Campaign
Sometimes continuous deployment is impossible or undesirable. In that case, For example, your marketing strategies may demand consistent release cycles, which aren’t always possible to synchronize with an app store or code release. In that case, feature flags will still be of great value.
In that case, you can launch the features into your application while having them disabled.
How to Deploy Feature Flags?
Deployment of feature flags requires extensive planning, careful implementation, testing, and maintenance to ensure features are working as expected and resulting in applications’ engagement. Deployment of feature flags is based on the following steps:
1. Features to be Toggled
Decide what features of your application will be toggled using feature flags. These can be the features that you want to save from the hassle of redeployment or are needed for a short duration in your application. You can also start with certain features and then gradually add more if required.
2. Choose Your Tool
Select or shortlist the flagging tool that best suits your applications’ needs and integrates well with the developer's needs. Popular tools used for flagging are LaunchDarkly, A/B Smartly, and Split.
3. Implementation
Once tools have been integrated, the feature flag code must be added to the application. Feature flag code usually consists of conditional statements to check if it is enabled for the users.
4. Rolling out Features
Once the code is in production, the features can be released using the feature toggle. The first roll-out must be done to a subset of users for beta testing to rectify bugs before releasing the feature to a vast audience.
5. Monitor and Maintain
Once the feature flag is live for all users, it must be constantly checked to ensure it works as intended and is bug-free. Various analytics tools can be used for the same.
6. Removing Feature Flags
Once the job of the feature flag is achieved and is no longer needed, it must be removed from the application’s main codebase to avoid technical complexities and performance issues.
Deploying feature flags involves intricate planning, testing, modification, and monitoring to ensure that features behave as expected and add value to the current application.
Challenges in Feature Flags
Feature flags or feature switches help save hassle for redeployment by introducing a toggle using which the functionality can be enabled or disabled with a single switch. Although feature flags are a reliable technique to deliver features, they can also face challenges sometimes. Somelenges are:
1. Performance Issues
Adding feature flag code into the codebase must be done with extreme precautions. If not done carefully, the main code can be cluttered with conditional statements and hence unmanageable, resulting in performance degradation. Removing the feature flag code is recommended once the feature is not required.
2. Testing and Maintenance
Implementing feature flags requires testing and maintenance to ensure the smooth working of applications across all platforms. Testing is necessary to ensure that the feature is working as it should. This adds to an increase in development time and complexity.
3. Configuration Management
As you keep adding feature flags to your code, managing the main codebase can become a cumbersome task to manage the main codebase. Planning, implementing, and testing feature flags is necessary, but we should also remove the feature flag once it retires via a clear process to prevent configuration issues.
4. Usability
Feature flags, if implemented correctly, can make users understand. While implementing feature flags, one must be careful about their usability. The feature flag should be engaging, and the feature should work properly after being enabled using the toggle.
5. Security Concerns
If not managed carefully, feature flags can be vulnerable to security breaches. For instance, if the flag is accessible to an unauthorized user, it can threaten an app and its users.
Therefore, following a clear process and strategy when designing and implementing feature flags is crucial to mitigate the impacts.
Feature Flags Used Cases
1. Enabling Testing in Production with Feature Flags
Feature flags allow developers and product managers to release features in production, validating the functionality of new features with a subset of live users. This allows for continuous innovation and, ultimately, in customer experience. This allows for continuous innovation and, ultimately, in customer experience. The data generated by measuring the feature’s impact on a business’s primary KPIs via experimentation can be used to make z decisions on whether to turn the feature on for all users. If the feature doesn't generate the expected improvement, it can be disabled.
2. Migrations
Sometimes, developers must migrate an app’s data that demands dependent app code modifications. Such migrations require tactfulness of the developers and multi-phase deployment. For this purpose, the development team might have to change, add, or eliminate a database field in an app database. If they fail to prepare the application code for such database modifications, it might end up causing blunders and errors. A coordinated deployment between the DB modifications and the application code becomes necessary if it occurs.
Feature flags aid in reducing the intricacy of this situation by letting the development teams arrange advanced app modifications in a feature flag. Once the team modifies the database, they can toggle the feature flag to immediately correspond to the app code immediately. Doing so helps them eliminate the risk and waiting time for deploying a new application code. Also, it helps them eliminate the possibility of deployment failure and app desync from the DB.
3. System Outage
Developers also make use of feature flags as system outage tools. For instance, web apps can turn off their entire site for maintenance or some other reason using feature flags. Development teams might equip feature flags over the codebase to push sensitive transactions and show visitors' outage content. It can be tremendously useful while performing sensitive deployments. Also, developers can utilize it if an unforeseen problem gets detected and requires urgent fixation. Therefore, feature flags give developers self-confidence and opt for a controlled outage if needed.
4. Experiments
Another primary use of feature flags is seen during experiments or A/B testing. Feature flags typically serve as a toggle to turn off or on a feature. Similarly, advanced feature flags are perfect for enabling different experiences for a limited number of users by using numerous flags simultaneously. For instance, you break up your user base into thirds. Each of the three parts of the user base gets its exclusive flag and user experience. Now, you can observe how these three flags perform and pick the best out of them as the final version. This helps developers who want to provide their product users with the best possible features and experience.
5. Continuous Deployment (CD)
Feature flags have another great use, and the development teams can utilize them as an integral apparatus for constructing a continuous deployment system. This kind of deployment system is a mechanized pipeline that gathers new codes from developers and auto-deploys them to the product's users. Such a deployment relies on mechanized test layers that help test expected new code behaviors against a corresponding specification as it travels via the pipeline.
Feature flags help make continuous deployment safer by extricating code modification-ling features to users. FYI, the continuous deployment system oversees user behavior and traffic and auto-enables that feature flag. Consequently, new codes get auto-merged and deployed to production and then stay behind a feature flag. In reverse, the continuous deployment system can oversee the latest feature flag code to see if its behavior matches the expectations and turn it off if it doesn't.
An even safer approach is replicating real-time requests from real users to a sandbox where the feature flags are turned on. The tests are run with real traffic without affecting the end users. The features that pass the test are turned on in production afterward.
Feature Branches vs. Feature Flags
Feature branches and feature flags are used to add features to any existing application; they require planning, implementation, testing, and maintenance before the new feature is rolled out for the users to explore. Both software development techniques have pros and cons; choosing which one to use depends on the application's needs. Let us get an overview of the differences between them.
Feature branches are created as separate branch of the code that consists of changes to the new feature to be added. Since the code is in a separate branch, it is debugged and tested separately from the main branch of the code. After the code is completely tested, the branch with the feature code is finally merged into the main code branch. Feature branches are suited for larger features requiring significant development and testing as the feature code can be coded and debugged separately, allowing for detailed testing.
On the other hand, feature flags opt for a controlled way of releasing new features. The feature code is implemented within the main code, unlike in the feature branch, where a new code branch is created. The feature code, however, encompasses a toggle that can be flipped on or off. So, the feature flags are tested and released for specific users in a controlled environment before public rollout for its customers. Although feature flags are used for frequent releases and don’t require much development and testing effort, they can still add complexity to code if not maintained carefully. Hence, once the feature flag job is completed, it must be removed.
Feature Flags in A/B Smartly
Features can be deployed and toggled in the A/B Smartly platform and run as part of an A/B Test. Engineering and product teams can easily deploy new features, collect data, and determine whether they should be continued. Through this continuous feature delivery process, companies can increase development velocity.
Conclusion
Considering the advantages mentioned above, you must have used feature flags to handle better and moderate your software deployment. Undoubtedly, feature flags are the handiest options to launch new features in your deployments while retaining their functional properties. So, we suggest you rule out other options and use feature flags to manage your deployments’ new features effortlessly.
People are also reading: