The Feature Flags technique was popularized by companies like Facebook and LinkedIn who wanted to release new features to a small group of users for instant feedback, and use that to influence decisions for a wider roll-out. Today, they have become an essential part of any developer’s toolkit.
“Feature Flags are a powerful technique, allowing teams to modify system behavior without changing code”
– Pete Hodgson on martinfowler.com
Implementing Feature Flags is as easy as having a simple toggle:
Feature Flags have evolved over the years, and are used in several scenarios.
- Release Flag: Enable true CI/CD
- Avoid creating a separate feature branch and branch merge nightmare
- “Decouple feature deployment and feature release”
- You no longer need to dread the big launch day. Your code would have been in production for several days or weeks before it becomes open to users
- Experiment: Canary testing or A/B testing. Release new features to production to a small population of users. For instance:
- Release new UI feature for users who opted in for beta testing
- Entitlement/Access Management: Unlike most other feature flags, this type of flag has a longer lifecycle
- Control access to features based on user access level, subscription category, and so on
- Ops Flag: This is essentially a manual circuit breaker
- Kill-switch that offers gracefully degradation of a system under stress during peak load, but maintains essential features
- Essential for any feature that would impact the performance of the system
- Business Flag: Enable or disable feature based on geography, time of year, and so on
- A global app that enables features based on the country you are in
- Enable free subscription for just a weekend
While Feature Flags are a great tool in any developers kit, it has to be used with care.
The rest of the blog explores key components of Feature Flag implementation, best practices, common pitfalls and how to avoid them, and lastly, tools that you can use instead of reinventing the wheel.
Feature Flag-based Progressive Delivery
From my personal experience, I believe this is one of the most significant uses of Feature Flag.
Agile Development methodology improved on waterfall methodology and promised delivering business value at a much faster rate. We take smaller pieces of the product backlog and deliver business value when each one is developed, tested, and released to production. This tightly integrated Continues Integration and Continuous Deployment (CI/CD) process is a key ingredient that makes Agile successful.
Now assume you need to work on a major feature, which would require several sprints to complete. A typical approach would be to use a feature branching strategy: create a feature branch, work on the feature, and once ready, merge it into the main branch and productionize. However, this approach brings back nightmares of waterfall development. The branch merge is known to be cumbersome, prone to errors, and introduces a high degree of risk/unknowns.
The key to avoiding such a scenario is using “Release Feature Flags,” and ensure continuous integration of code – even unfinished feature (yes, you heard right!) and deploy it to production. All you need to do is have the flag turned off. Once the feature is fully ready, simply turn it on.
Release Flags help separate the feature release and deployment. They enable true Agile Development and CI/CD. Many have dubbed this as Progressive Delivery.
Note: Not to be confused with feature branches with pull requests that are required as part of standard development practice. And Release Flags are typically short-lived. This is an important aspect. More on this later.
Targeted Roll-out of New Features
A/B testing, canary testing, experimentation in production, selectively enabling features for users belonging to a certain group or geography, are examples of use-cases for the next category of Feature Flags.
I recommend that you use one of the pre-built feature flagging solutions available, instead of having to build something from scratch. While it would seem simple enough to start, there are a number of capabilities that you need, to implement a robust feature flagging solution. Some of thesw capabilities include:
- Control % roll-out, user group configuration, geography configuration, and so on
- Support for cascading flags/dependency evaluation
- Audit and access control: who can change flags and track, who changed the flag
- Multivariate flags
- Handle millions/billions of flag evaluations per second
- 100% uptime and redundancy
- UI that can be used by end-users to flip the switch
Instead of building these features from scratch, use any one of the open-source or paid services available, that meet your requirement:
- Launch Darkly
- any many more options available
This will allow you to focus on feature flag-based development instead of developing the flagging infrastructure.
Note that based on your requirement of server-side or client-side evaluation of feature flags you need to select the appropriate tool.
Best Practices and Avoiding Technical Debt
While Feature Flags are a great tool for any developer, indiscriminate use and lack of management can result in spaghetti code which is difficult to maintain. Improper usage and management can also result in significant business impacts.
- Each feature should have its own flag. Never re-use a flag
- Appropriate naming of each flag is vital to avoid any ambiguity
- Short-lived flags such as release flags, experimental flags, etc. should be promptly removed once the feature is live
- Control and audit access to flags
- Look at breaking down the feature sufficiently before looking at Release Flags
While the approaches discussed here are applicable for application code, you can look at flags to handle database-level changes. With microservices/document databases like MongoDB, we can have multiple schema versions and have a flag in the application to determine which version to use. However, when it comes to databases, there are a number of considerations and are, in general, more complex – purely because of the current state of the database engines. Something to explore in detail in a future blog.
Feature Flags have been helping leading technology companies such as Facebook, LinkedIn, Netflix, and others with rapid development and release of new features without the fuss of complex code/branch merges and launch-day jitters and risks. You too can benefit from adopting feature flag-driven development. Follow the best practices and manage your flags well. Don’t reinvent the wheel unless you have to and use the solutions already available.
- FeatureToggle (martinfowler.com)
- Feature Toggles (aka Feature Flags) (martinfowler.com)
- Build or Buy – Feature Flags, Toggles, Controls
- Best Feature Flag Management Tools for $100 | Medium
- Feature Flag Best Practices (oreilly.com): Book by Pete Hodgson and Patricio Echagüe
- When Feature Flags Go Wrong (infoq.com)
- Facebook: Taming Complexity with Reversibility
- Preparing the Netflix API for Deployment | by Netflix Technology Blog | Netflix TechBlog
- Flipping Out | code.flickr.com