Many developers say that they use feature flags or feature toggles, but this year we have realised that there is some confusion around the term that still persists. Therefore, we decided to write an article about Feature toggles and feature flags, taking into account it’s increased popularity.
As software teams seek higher agility, the tools and techniques for software development and delivery continue to evolve every year. DevOps and CI/CD practices provide a solid framework that allows teams to release software with increased automation and with less risk. One of the best ways to do this is to incorporate feature flagging into software development practices.
Championed by influential Martin Fowler, continuous delivery is a software development discipline in which software can be released to production at any time. It has been adopted by leading software companies around the world whose teams are now expected to quickly deliver software that is stable and bug-free to your user base. Feature flagging enhances continuous delivery and continuous integration by making “continuous” more achievable. The feature flags and feature toggles are a key component of the implementation of continuous delivery, allowing the separation of feature rollout from code deployment. Incomplete features can be merged into the production codebase but hidden behind feature flags. With continuous delivery and feature flag management, a team can launch, control, and measure their features at scale.
Feature toggles or feature flags allow you to toggle a feature on or off at any point of time, even after you have deployed your code. They help you take control of your releases by sending new features to specific audience segments and allowing you to choose the exact percentage of your users that receive an experiment. And feature toggles became more about full feature lifecycle management – managing the feature from development, to QA, and to production. They can also be a way to aggregate performance analytics and test the impact of a feature on your system’s architecture.
Well, before moving on, let’s make it clear for everyone, what are feature toggles?
Feature Toggles (often also referred to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code. This enables developers to take full control of their feature rollouts, dark launch, and roll back poorly performing features.
This led to the rise of open source feature toggle libraries tailored for specific languages, like Java and PHP. Feature toggle is used to hide, enable or disable the feature during run time. For example, during the development process, a developer can enable the feature for testing and disable it for other users.
Feature toggles are essentially variables that are used inside conditional statements. Therefore, the blocks inside these conditional statements can be toggled ‘on or off’ depending on the value of the feature toggles. A block of code which has been toggled ‘off’ is similar to it being commented out. This allows developers to control the flow of their software and bypass features that are not ready to rollout. However, one of the most common usage of feature toggles is to avoid conflict that can arise when merging changes in software at the last moment before release.
Feature toggles can be used in the following scenarios:
- Adding a new feature to an application
- Enhancing an existing feature in an application
- Hiding or disabling a feature
- Extending an interface
It is important to mention, that feature toggles require a robust engineering process, solid technical design and a mature toggle life-cycle management. Without these 3 key considerations, use of feature toggles can be counter-productive.
Feature toggles fit well with the practice of Continuous Integration and Delivery (CI/CD) and with techniques like A/B testing and canary releases.
There are a number of types of feature toggles, but let’s look at the most popular ones:
Sometimes individuals on a team are working on a feature that may take many sprints to complete. In this case, a release toggle can be beneficial for a team using CI/CD to allow a feature team to work in the same integration code branch used by the rest of the team. A release toggle enables the developers to quarantine off their unfinished feature from the rest of the code base and turn on and off the feature in local development environments for testing.
There are a number of reasons a team may want to use an operational or ops toggle to turn on or off a feature in a production environment. One use of the ops toggle is on a feature that may have an unknown performance impact in your production environment. If the new feature is noted to degrade system performance, you could quickly turn it off to prevent greater system failures.
This type of toggle is probably more common in the commercial sector. When you are experimenting with a new type of workflow, such as a new user interface component or a new way of reporting data, and you want to have your actual production users provide feedback or analyze their behavior using the feature. The experiment toggle allows you to perform A/B testing sending different users down different paths so you can figure out which feature—A or B—works best for your users.
They allow to change the features or product experience that certain users receive. For example you may have a set of “premium” features which you only toggle on for your paying customers.
One of the more obvious benefits of feature toggles is that they allow you to release new features that are still under development. Since each new feature is behind a toggle, it won’t go live until you decide to turn that toggle on. If you have a method of updating your toggles in production, development schedules can be separated from deployment schedules. The pain and risk of late night releases gets replaced with the click of a button that can happen at any time.
Feature toggles are especially useful for speeding up the development process when combined with Continuous Integration and Delivery. Rather than working on long-lived branches that become difficult to merge, work can be done in small pull requests that get merged frequently to the main code branch. Developers are more productive, because merge conflicts are dealt with when the context of a change is still fresh in people’s minds. Bugs can also be handled more efficiently with feature toggles. If someone finds a bug with a feature that’s behind a feature toggle, you can immediately switch off the toggle. Not only does this prevent the interruption and risk of rolling back changes, it allows new changes to continue rolling out to production so your pipeline stays fast and productive.
3. A/B Testing
Feature toggles are a nice way to ease into experimentation to test out ideas and learn what works best for your users.
Ideas for improvement don’t only come from the product or UX team, they come from engineers, too. Feature toggles make it easy to test assumptions and once people start seeing their ideas brought to life and validated, they feel more invested in the product and the process and “I don’t think that will work” gets replaced with “Let’s try it out”.
Feature toggles help push the team culture towards embracing change, rather than shying away from it. As a result, there’s less pressure to make things perfect the first time.
Safely test features in production while rapidly collecting valuable user feedback. Many popular apps like to use feature flagging to see how users respond to new features. As they receive positive feedback and gain confidence in the feature, they increase the number of people who get the new version with no app updates required.
6. Mitigate Risk
You have the ability to rollback your product or feature immediately if you detect a bug or encounter negative feedback that could cost you your reputation.
7. Update already live features
Make changes to live features without having to redeploy or require app-store updates.
Actually, new buzzword came out: feature flag driven development, which is about harnessing the power of test-driven development (TDD). This is the process of releasing and iterating features quickly, testing those features, and making improvements. You release light features to receive market feedback. You iterate on that feedback, make improvements, and redeploy. Feature flag-driven development is a way to receive iterative market feedback on your product, rather than solely depend on isolated customer feedback. It’s a way to test how your features perform in the real world and not just in an artificial test environment.
Although there are numerous advantages, there are some risks in feature flag management that may lead to technical debt. And here are the top ways for managing your feature flags better:
- Flag naming A proper naming convention for feature flags is the first step towards better management. In the absence of a naming convention, it’s possible for team members to confuse the flags or worse, create flags with the same name. If you don’t label your flags carefully, someone in your team could mistakenly trigger these flags, which can lead to severe disruptions in extreme cases.
- Logging In order to track changes better, consider logging all the changes to a feature flag. If you set up logging, you can track who introduced a change, and at what time. In distributed teams, this can save numerous hours in figuring out who is responsible or has the rights for a particular change.
- Separation of flags Feature flags can be primarily classified into two different types: release flags and business flags. Release flags allow development and operations teams to hide under-development or risky features temporarily, while business toggles are used on features that are stable but have to be hidden or made visible to select audiences only. Managing the two types of flags in different configuration files can help you reduce complexity and streamline support and debugging.
Feature toggling is used by many large companies including Flickr, Disqus, Etsy, reddit, Gmail, Netflix and Apiumhub. And Feature flags work well but in general it’s best to keep feature flags short-lived and small in number. Too many flags or long-lived flags add complexity and are deliberate tech debt. Cleaning up feature flags is important to keep a codebase sane. Using feature flags can help companies to ship more often, minimize risk, increase productivity, and even help with targeting users and A/B test features. Evaluating company’s branching strategy with feature flags can be very powerful, especially if you need to ship frequently.