1

For developers that use Trunk-based development, how have you approached dealing with an ever-growing collection of feature flags in your codebase?

My concern is if you are heavily leveraging feature flags for every release and every new feature, wouldn't the amount of feature flag code start to make the code less readable and possibly harder to maintain? For the sake of this question, assume feature flags are being handled by an external FFaaS.

Based on my own reasoning I can see a few options:

  • Never delete feature flags. Keep them around in case you may need them (ie for sunsetting a feature you are phasing out at some later date).
  • Periodically remove old feature flags that have remained on for X amount of time. This solves the code readability issue, but this breaks the trunk-based deploy paradigm as you lose out on the fallback measure of turning on/off a flag since the flag itself is being removed. You may also lose out on the above case where you'd have to manually track down functionality to phase out, or maybe re-introduce feature flags back in to facilitate some similar transition.

How have people handled the logistics around using this development system?

Glen Cooney
  • 107
  • 5
  • "fallback measure" isn't meant to be a permanent solution. At some point you have to accept the risk of your code still having bugs you haven't found, but still you remove the "old way" of doing stuff, without the feature flag in place. You can't have 1 version of the software in production **with every version of every feature of every release** still in place. Start removing old feature flags. Old as in, will never be turned off again. – Lasse V. Karlsen Sep 24 '20 at 19:30
  • The way we do (well... try to, I'll admit we also have a few long-living feature flags still present) it is that once we deploy a new version into production with a feature flag, we also create an issue in our project tracker to remove the feature flag. This removal also means permanently enabling the new feature, and thus not only getting rid of the if-statements and the flag itself, but also any old code that the new one replaced. The feature flags only make sense if you keep them temporary, otherwise you're going to add too much complexity, as you've already discovered. – Lasse V. Karlsen Sep 24 '20 at 19:33
  • Also, don't use feature flags for enabling stuff for customers, those are options, modules, licenses, etc. Feature flags is a tool for deploying and testing, not a crutch for avoiding adding a license system where different customers see different stuff. And yes, sometimes you will enable feature flags for specific customers, but that is in testing context, not in a "this customer now bought module X" situation. For that you need something else. – Lasse V. Karlsen Sep 24 '20 at 19:34
  • However, in the end, the only one(s) that can really answer this question is yourself. All the rest of us can do is provide opinions and anecdotes. You will have to settle for your own process. If you see problems with leaving the feature flags in place, have a workshop where you discuss the alternatives. **There are no 100% ideal solutions**, they're all compromises. So find the compromises you're willing to live with. – Lasse V. Karlsen Sep 24 '20 at 19:37

0 Answers0