Feature Flags (often also referred to as Feature Toggles) are a powerful technique, allowing teams to modify system behavior without changing code. (MartinFowler.com)
Feature Flags explained
If your software development team is on the journey to adopt #DevOps practices, increasing maturity with continuous deployment pipelines and trunk-based development will likely introduce bottlenecks in various stages of your release process. For example, the team is developing a feature incrementally and merges to trunk multiple times a day, however the feature is still not fully complete and not ready to be used by customers.
In this case the "feature flag driven development" concept comes to the rescue. Feature flags can be introduced into your application to allow for new features to be hidden until they are ready for release, regardless of whether they’ve been deployed to production. In other words feature flags control visibility of the new feature to your users. Another relevant example of when you may want to introduce feature toggles is transformation of the traditional release process. If you are on the journey of convincing your release manager that CAB meetings and manual approvals are not the way to deliver software anymore — feature toggles could be a powerful weapon to reassure them that production deployments can be performed safely with reduced stress and risk.
Although the concept of feature flags (or feature flags) has been around for quite a while there are still uncertainties around when to use it, how to implement it and how to test it so the quality of your application is maintained at the highest level.
In this article I will try to cover the main benefits and best practices around feature flags and how to ensure these are working as you expect.
Key benefits of the feature flag concept
Allows you to continuously push your feature code changes all the way to production even if the feature is not finished
Faster and safer iterative code deployment process, less risk
Helps developers and testers to keep the development flow uninterrupted
Removes pain associated with long lived branches
Features can be turned “on” or “off” by a product owner
Features can exist across your entire application stack from front end all the way down to services
Easy roll backs — in case something goes wrong, just flip the feature flags
Best practices
As with any other technical solution feature flags introduce complexity into the system and it is very important to keep it under control and not let it grow into a technical debt. By following some basic rules you can reduce this risk and prevent feature toggle mess:
Features should be non-dependant on other feature flags
Do not accumulate features in production, once they are turned “on” the code associated with “toggling” should be removed
Choose carefully which functionality should be behind a feature flags based on observability to your app users. If some piece of functionality doesn’t affect how end user interacts with an app perhaps this piece doesn’t need to be behind a feature toggle
Test toggled functionality and make sure the automated tests are running in your CD pipeline. It is ok to have two sets of tests for feature “on” and “off” states
Give business folks responsibility to decide when to turn a feature “on” in production
Introduce feature flags management tool, provide visibility to the business, for example display feature states and provide them with a way to easily toggle features on and off. There are a couple of open-source and commercial tools available on the market, like #FeatureHub.
Happy feature flagging!
Comments