Feature flags seem to be recurrent topic in few recent conversations I had. More so, misconceptions about them seem to be one of the major obstacles on the road to adoption of Trunk Based Development.
Foreword – Context
GitFlow is dead, long live Trunk Based Development.
This is no longer a secret. If you want to be competitive in modern software delivery landscape, you have to adopt Trunk Based Development (TBD). Otherwise, the time lost on merging things and related errors will trump any types of gains elsewhere. Merge is always the greater evil.
Feature Flags – No1 Concern in TBD Adoption
When people first hear about TBD, they always ask – what if I only want to cherry-pick some changes from Develop branch to go to production – how do I do that with TBD?
The answer is “You don’t do it this way, and it’s a good thing”. First, realize that what you really want to cherry-pick is a certain feature or functionality – not the code. Actually, you would very much prefer to not to cherry-pick code ever (merges are evil, remember?)
So if you have a half-baked feature that needs to be cherry-picked, you should code it in such a way that there is some sort of toggle which lets you disable or enable it on demand. This toggle is usually referred to as “Feature Flag”.
Once you have such toggle in place, you simply make sure it’s disabled in production. With that, you have just achieved your goal – your code base is stable across environments, and you are able to cherry-pick desired functionality which goes into production.
But Feature Flags Software is Expensive
This is the next big concern that I hear at this stage of the conversation. Yes, there are free tools in the space – notably Unleash has OSS version – but still it comes with significant maintenance costs.
The good news is – in majority of cases you do NOT need any specialized feature flagging software. Generally speaking, you only need specialized software if you have requirements for non-technical people to toggle features. In example, if you want marketing people to play with look and feel or trigger exact timing of specific update.
However, if this doesn’t apply to you and you are in the majority – all you need is environment variables that would represent your feature flags.
Any modern delivery tool would then be able to use those environment variables to control desired behavior per environment. For example, on Kubernetes this would be trivial to achieve via Helm or Kustomize.
Feature Flag Complexity
Yes, they become complex if there are too many of them. So it is recommended to establish regular process of removing legacy feature flags.
Say every 6 months, check for all features that have fully converged – that said they are not half-baked any more and are enabled across all environments. Once converged, you no longer need to parametrize them – all those related toggles and dedicated environment variables are now obsolete.
Simply remove those legacy feature flags and instead enable the latest and greatest version in code unconditionally – and this is how the system is kept manageable, and you are not overwhelmed with parameters.
And yes, this regular maintenance takes some time, but this is nothing compared with regular large code merges we saw in GitFlow.
TL&DR
- Trunk Based Development is the king
- In TBD we do not cherry-pick changes, instead we keep the code stable and parametrize things – via feature flags
- In majority of use-cases you do not need specialized software to do so, regular environment variables will do
- Have regular process to clean up legacy feature flags to keep their numbers manageable
1 comment