what they are and how to use them
Feature flags have become a staple for devops and software development teams to release features quickly and safely. Feature flags can be used for a wide range of purposes and are referred to in a number of ways from feature toggles to feature flippers but the core concept remains the same.
This guide will take you through the concept of feature flags, why and how they are used by teams today, their implementation and some of their pros and cons.
Feature flags are a software development tool whose purpose is to turn functionalities on or off in order to safely test in production by separating code deployment from feature release.
Thus, a feature flag ranges from a simple IF statement to more complex decision trees, which act upon different variables.
There are many types of feature flags, categorized based on their dynamism and longevity that serve different purposes.
When we talk about longevity, we are referring to feature flags that are either meant to stay in your system for a short period of time while other flags could stay for years.
For example, feature flags may be short-lived to temporarily deploy new changes and test in production while other long-term flags, such as kill switches, remain in your system longer. Therefore, you will need to manage different feature toggles or flags depending on how they’re deployed.
Keep reading: Short vs Long-lived Feature Flags
In terms of dynamism, which is how often you need to modify a flag in its lifetime, there are two categories of flags:
- Dynamic- allow their value to be changed at runtime.
- Static- only change through actual code changes or configuration file changes.
To learn more about the differences between static and dynamic flags and where to store them depending on which category they fall under, read our best practices article on where to store feature flags.
We can further break down feature flags into various categories of toggles, which should be managed differently. In other words, you will need to manage different feature toggles or flags depending on how they’re deployed. The main categories are:
- Release toggles
- Experimental toggles
- Operational toggles
- Permission toggles
For more details on these different categories of feature toggles, refer to this article.
In that sense, feature flags allow teams to practice trunk-based development without the risk of long-lived branches and the dreaded merge hell.
Feature flags allow you to continuously test in production without risks. This way, you can release your features much faster to your users and since you’re continuously validating your changes on a subset of users, you end up with higher-quality and less buggy releases.
With time and as use-cases evolve, using feature flags can become complex, especially as some organizations opt for an in-house system which can lack the level of sophistication necessary to support your products.
If stale, unused flags remain in your system, this would eventually lead to the accumulation of technical debt so flags will need to be cleaned up once they are used and are no longer active.
- Waterfall methodology is more of a traditional model. It adopts a linear approach to software development where each phase flows downward, like a waterfall, to the next; each stage must be completed before the next one begins.
- Meanwhile, Agile methodology is one that takes on a team-based approach to development. Instead of planning for the whole project, it breaks down development into small batches completed in stages. What makes Agile development innovative is it shifts the focus to the user as it relies on a very high level of customer involvement throughout the project.
- Trunk-based development is a branching model where developers collaborate in a single branch and make smaller changes more frequently. The idea behind this practice is to limit long-lived branches that may lead to ‘merge hell’. This is usually a good strategy to use to get features out fast.
- Feature branching, on the other hand, is when developers work separately on a branch and then once their changes are completed, they merge them into the mainline. This is an efficient method to manage large-scale projects with a large number of developers working on specific features.
Control access to flags
Set up logging to know which change was made by who-this is especially important to reduce dependency between product and engineering teams and better productivity as there will be greater transparency particularly when it comes to introducing new changes.
Use a standardized naming scheme
In the absence of a naming convention, people in your team could start naming flags with the same name and getting flags mixed up. This could result in your team activating the wrong flag leading to potential disruptions in your system.
Manage different toggles differently
Conduct regular clean-up of your flags
A typical feature flag implementation is based on (1) a management service that defines the flag, (2) a run-time query to figure out the value of the flag, and (3) an if-else programming construct.
There are many ways to implement feature flags. The simplest and often the starting point is to use if/else statements directly in your code.
You can also rely on open source projects and many libraries are available for your preferred programming language. Read more about the Top 10 feature flag related projects on GitHub.
However, feature flags go beyond simple boolean states to more complex logical statements. Therefore, if you want to delve into more advanced uses, you will need more complex feature flag management tools.
Before embarking on your feature flag implementation journey, it is important to consider the following:
- Identify pain points– it is important to consider your objectives and what issues you are trying to tackle in your software development process and in production.
- Determine your use cases– in other words, consider why you want to use feature flags and who will be using them in your organization besides developers.
- Consider whether to build or buy– there are many factors to consider when deciding whether you’re better off building or buying a feature flagging management system.
Once you’ve decided you prefer to get a 3rd party solution, choosing the best feature flag management service to match your needs may prove to be a challenge. Visit our feature flag service comparison section to see how AB Tasty stacks up against other solutions.
AB Tasty’s Feature Experimentation and Experience Rollouts may just be the solution you’re seeking, where it has been dubbed as a leader in the The Forrester New Wave™: Feature Management & Experimentation, Q2 2021 report.
AB Tasty not only allows you to turn features on and off but it gives you full control over your feature releases by wrapping your features in flags and rolling them out based on the specific flag values you assign to different user segments. You can then make informed decisions according to the metrics and KPIs you choose.
If you would like more information on getting started with our server-side functionality, check out our documentation to help you get started.
Feature flags are a software development practice whose purpose is to turn functionalities on or off without the need to deploy new code, and therefore to separate code deployment from feature release.
Feature flags enable continuous delivery by allowing teams to practice trunk-based development without the risk of long-lived branches and the dreaded merge hell. They also increase development velocity by making test in production simple so you can continuously validate your changes on a subset of users while mitigating risks. They are not only used by engineering teams but also by QA as well as product and operations teams.
Feature flags are often referred to as feature toggles and vice versa. However, it can be argued that as feature toggles evolved from an on/off switch to expand to more use-cases, feature flags became a more appropriate term.
Remote config can be implemented through feature flags. With remote config, features added to your mobile app can be wrapped in a feature flag and toggled on and off remotely when deciding who gets to see the new features.
A feature branch is when each developer makes a copy of the codebase in the trunk into a branch where they can make their changes and merge back into the trunk once they are done. Read more about Git branching strategies.
Feature branching sometimes is done using feature flags, especially when one developer is not yet finished with their changes but the release can still occur. Feature flippers would allow you to turn off these unfinished changes while completed features can still be released without delay.
To a certain extent. Both help you ship more confidently. With an A/B test, you can run experiments and choose which version of your website to show to your visitors. However, you can also run A/B tests on features of your website using feature flags. Here, you can create two variations of your feature to a subset of users and then you can analyze how the user experience differs with the new feature.
With that said, A/B testing is not the only testing in production technique you can implement using feature flags, so they can help you run A/B tests but their uses extend beyond that.
There are three common ways to implement feature flags.
First, the do-it-yourself method where you develop and maintain your flagging system on your own, using a bunch of if/else statements and some configuration file or database to control flags. This can be suitable for simple use cases.
If you are not willing to maintain a dedicated codebase, you can rely on open-source libraries.
Lastly, if you have hundreds of flags and advanced use cases like feature targeting and experimentation, the use of a managed feature flag management platform is probably the best choice.
More Feature Flag resources
Throughout the coding and testing process, developers find themselves having to switch between a lot of different tools. At AB Tasty, we’ve understood that this
David Mannheim explains a remastered approach to personalization for long-term customer loyalty With over 15 years of experience in digital businesses, David Mannheim has helped
Maximize the Potential of Experience Optimization Platforms: Key Questions to Ask for Performance Success
In the dynamic realm of e-commerce, selecting the right experience optimization platform (EOP) is essential for achieving success. But, how do you assess the impact
In modern software development, teams adopting a DevOps methodology aim to release more frequent releases in smaller batches to validate them and test their impact.