There are of course other ways to use feature flags. It all depends on the context: the longer a feature flag will exist, the more effort you want to put in, and the more advanced the solution probably will be.
Implementing and configuring the feature flag
Another thing to consider is how to implement the feature flag itself. There are a few tips:
- Don’t use magic strings to name the flags. No ConfigurationManager.AppSettings[“MyFeatureFlag”]. This is error prone and it’s easy to miss a flag when cleaning up. The compiler certainly will not help you with any typos you make.
- Make sure you clean up the flags that are not being used anymore. Using release feature flags, especially when using multiple flags at the same time, introduces some technical debt that must be fixed as soon as possible.
- Separate the flag’s definition from its use. Create some centralized place where the flag and its state are defined, like a factory. It will help with managing the flags in use and with cleaning up unused flags.
- Do not set a default value. If you forget to configure the state of the flag, don’t let the application assume the correct value; just throw an exception.
Some changes are hard to accomplish in a multi-user environment, even when using feature flags. Spend some time thinking about your approach before implementing feature flags, especially in these scenarios:
- Implementing a breaking change to the data model. These changes are difficult to roll back, and yet toggling a feature on and off requires just that. You might be able to implement the new data model and change the existing code to work with that. Or this change should be done in a feature branch after all;
- Implementing a large refactoring that changes a lot of code. Putting all these changes behind toggle points will make the code hard to read and maintain, even for the short period this feature flag needs to exist. You will probably be better off using a feature branch.
You will also need to think about where to configure the state of the feature flag. Common scenarios include:
- In code. This is very easy to implement, but you do need to recompile and redeploy the application if the flag is toggled;
- In a configuration file. Again, relatively simple, and you can switch the state of the application at runtime;
- In a database. This is a bit harder to accomplish, but it offers more flexibility, like toggling the flag runtime, creating a user interface for managing the toggles, or combining the toggles with a membership provider to turn on the new feature for some users. Business feature flags will almost always use this type of configuration, since they relate to groups of users.
There are frameworks available to help with implementing and configuring feature flags, such as the NuGet package FeatureToggle by Jason Roberts. This well documented framework will help you get quickly up to speed.
Feature flags and CI/CD
A great use for feature flags is in a CI/CD environment. Without feature flags, a new feature will typically be developed in a feature branch if it consists of multiple work items. As each work item is finished and checked in, the feature comes a bit closer to completion. Once all the work is done, the feature branch will be merged back to the main development branch and from there start its journey through the build and release pipeline. You need a feature branch to be able to release other work without also releasing a half-finished, non-functioning feature. But merging code has to be done manually, so this feature will not be automatically included in a CI/CD release.
Back to our situation, where we can now develop all code in one and the same branch, using our new feature flags. As soon as a work item gets checked in, it will be built and released through our CI/CD pipeline. As long as the feature flag is not set, the unfinished feature will not be available in the release, even though code from that feature is present. Only when the feature flag is set will the new feature be available in the release.
Conclusion
If you want to get rid of those difficult merges, or you are moving towards a more automated build and release strategy, you might very well benefit from feature flags. If you would like to read more about feature flags, Pete Hodgson has written a nice article about different scenarios for using feature flags and when to use what on Martin Fowler's site: https://martinfowler.com/articles/feature-toggles.html. If you want to see feature flags in action, look at this simple code example: https://github.com/ArnoudBM/FunWithFlags. And start using them yourself. It’ll be fun, I promise.