Some Thoughts on Toggles
Best practices for toggles.
Join the DZone community and get the full member experience.Join For Free
Kent Beck was asking about “Feature Flags” on Twitter recently and their life cycle. Former colleague, Pete Hodgson linked back to an article he’d written to for Martin Fowler a couple of years ago, and added context.
I don’t think this article fits in that Tweet series, so it’s a standalone blog entry — much of which I’ve shared before.
Some toggles shape what is built — things are included or excluded from binaries (JARs, DLLs, EXEs, APKs etc).
They are also known as “build-flags”, and they have a multi-decade history.
Boot or Run-Time Toggles
Some toggles go with the binary into an environment (QA, UAT, Prod, etc). They are noted in XML, JSON, YAML, TOML, or HOCON.
In theory, they could be edited in-situ and a process restarted or bounced and the toggle would cause something to change versus before. There’s a challenge here, in that the toggle state is now per VM (unless in a network mount), or divergent to something that might help in some canonical place. Naive solutions might have toggles that work this way in code (Java, C#, Python, etc) and that are a God class of sorts — active in assembly, composition, and configuration of the thing being stood up.
It is also clear that modern horizontally scaled cloud deployments don’t give you access to the deployed piece in this way, as deployers consider deployments to be eminently re-creatable (and ephemeral). Serverless architectures are thought to be even more so.
Toggles That Can Be Changed Without Restarting an App or Service
Some toggles can be changed centrally (for an environment) and soon after changed toggle states have reached all horizontally scaled nodes without those restarting. Most likely, something like Etcd, Consul, or Zookeeper is used for the configuration distribution. (Officially, those are part of a “service discovery” category of software.) Of course, I think those should leverage source control too, but that’s a different topic entirely: “config as code”.
I’ll call these “hot toggles” at times.
Branch by Abstraction
The first mission that leveraged Branch by Abstraction had boot-time toggles that drove the “old” and “new” implementation choices for messaging tech (JMS vs Tibco) and message nature (binary vs XML). Both of those were concurrently developed with separate toggles. It took some weeks to complete the series of commits in "trunk" and make the final toggle flips to “new”. After that, when it was clear that prior choices were gone forever (no rollback), the old implementation was removed. That could have easily been a build-flag instead of a boot toggle, but we made a choice that worked for us. Later, we utilized build flags more, but the program was far longer and parallel development far bigger.
Toggles Usage Shouldn’t Prop Up Poor Branching Practice
I’ve heard it mentioned several times that Toggles can be part of a strategy of long-lived branches (i.e. some teams that are hell-bent on not doing Continuous Integration, as intended by Kent Beck and the XP community). These teams are juggling long-lived feature branches. That’s also true when multiple branches garner active development for releases or projects (instead of features) with an intention to bulk-merge later. Those CI-incompatible branching practices are to be avoided. Using toggles to prop up inherency complexity, risk, inefficiency, and waste is far from best-practice.
Published at DZone with permission of Paul Hammant, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.