Feature Flags in ToneStone
Feature Flags
Feature Flags
Git Branches are lightweight and incredibly valuable, but parallel develoment can be painful and expensive. Branches can diverge and conflicts emerge. Conflicts can be syntactic or semantic or both.
In a syntactic conflict the same lines of code were changed in two different branches. Syntactic conflict resolution almost always requires manual effort. Resolving the conflict can be a real mystery that takes time to unravel.
Semantic conflicts, on the other hand, are impossible for Git to detect. A semantic conflict means the two changes made different assumptions about the rest of the code base. What made sense in one branch is no longer correct given the other code change. For example, you might need to make calls in different order than before, but you had no indication of that.
Feature flags have existed for decades as a way to manage different versions of the software in the code itself, not using source code control. In recent years this approach as become more valuable, see Pete Hodgson’s article on Martin Folwer’s site.
Demo Video
I recorded a 4 minute video about some new Feature Flag infrastructure I created for a client, the music application ToneStone.
Cloud or Otherwise
Feature Flags have really blown up in the cloud world with blue/green deployments, staged rollouts, and A/B testing, however feature flags are useful in any type of software. They are a simple sharp tool to have in the toolbox.