Feature Branches vs Feature Flags
Many organisations use some combination of feature branches and feature flags. But how do you decide what combination will work for your organisation?
In researching for this article, I came across this blog post at Rollgate which pretty much covers everything that was on my mind. Feature Flags vs Feature Branches: When to Use Each.
So I will do a bit of a TL;DR of that article and conclude with a few of my own observations. Here are the main points:
It's not either/or, feature flags and feature branches solve two different but related problems: Feature branches allow control over code integration. Feature flags allow control over feature release.
Feature branches provide code isolation and allow checks before the feature goes into main. But they can be a burden if allowed to live for too long. I certainly relate to the "all-or-nothing release" comment. I've seen it too many times: the feature languishes in a branch, unable to be released until every idea that any stakeholder had about the feature has been implemented and second guessed and in all that time, not a single customer has seen it and even internal stakeholders have only glimpsed it in sprint demos but not been able to interact with it.
Feature flags give the flexibility to release anytime but introduce more complexity, expand the testing exponentially and can go stale.
The largest tech companies in the world use feature flags and feature branches: Google, Netflix, Meta and Spotify.
The rest of the article goes into more details on the nuts and bolts of implementing a feature flag service, git branching strategy and ways to prevent pitfalls such as stale feature flags.
Here are a few thoughts I had based on my experiences in this area:
In embedded software, feature flags have some added complexities. Since the software is versioned and needs to be rigorously tested, the cost of feature flags is greater. Typically embedded firmware updates come with a migration scheme that must upgrade the configuration. The migrations are now more complex because the different combinations of feature flags must be considered as well.
In embedded software, there are limited tools for feature flags. The solution is more than likely to be a in-house rolled solution involving hidden configuration flags. This also means there won't be dashboards and other tools to track which flags are running at any time. Explicit logging will be needed to ensure that support engineers can interrogate which feature flags were enabled at the time of a bug. If there are automated tools for collecting device state in the context of a failure, ensure feature flag states are included.
The complexity added to CI by feature flags can't be understated. It's not just about testing the feature itself but if that feature interacts with another feature, then the other feature must now be tested twice or some decision needs to be made about leaving some tests out and how to balance the risk.
Vertical slicing of features is essential for keeping feature branches short lived. A feature flag actually enables this. If the stakeholders are in an all-or-nothing mindset about feature delivery, then the small iterations of the feature can be merged to main safely behind a feature flag, avoiding a long lived feature branch.
Further Reading
Don’t Branch that Code! Feature Flags vs. Feature Branches