Feature flags— benefits and best practices

Feature Toggles (often also referred to as Feature Flags) are a powerful technique, allowing teams to modify system behavior without changing code. (MartinFowler.com)

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 toggle concept comes to the rescue. Feature toggles 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 toggles 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 toggles (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 toggles and how to ensure these are working as you expect.

Key benefits of the feature toggle 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 — just flip the feature toggle

Best practices

As with any other technical solution feature toggles 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 toggles
• Do not accumulate features in productions, once they are turned “on” the code associated with “toggling” should be removed
• Choose carefully which functionality should be behind a feature toggle 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 toggle 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. However you could also build your own feature toggle services if you want to have full control of what it should do.

Happy feature toggling!