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.

Build-time toggles

Some toggles shape what is built - things are included or excluded from binaries (JARs, DLLs, EXEs, APKs, etc)

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, HOCON or similar.

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 be in some canonical place. Naive solutions might have toggles that work this way in code (Java, C#, Python, etc) and that are God class of sorts - that is 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 even more so.

Toggles that can be changed without restart of app/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, Zookeeper or similar are 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 thing: “config as code”.

I’ll call these “hot toggles” at times.

Branch by Abstraction

The first mission that leveraged Branch by Abstraction (2005 - for an FX trading bank - 180 devs, many teams in one codebase) had boot-time toggles that drive 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. And the abstraction, and the toggle itself. That could have easily been a build-flag instead of a boot toggle, but we made a choice that worked for us. Later (an airline doing concurrent development of consecutive releases), we utilize build flags more - but the programme 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. teams that are hell-bent on not doing Continuous Integration community that would sit on top of Trunk Based Development (goes into some detail of branching/commits as a practice). At least, as intended by Kent Beck and the eXtreme Programming (XP). You’re team isn’t doing CI it is juggling long-lived feature branches. That’s also true when multiple branches garner active development for releases or projects (instead of features), intending to bulk merge back later. Later could be just before or just after a release. Those CI-incompatible branching practices are to be avoided and using toggles to prop up their inherency complexity, risk, inefficiency, and waste is not fooling those that defined or live in the worlds of XP, proper CI or CD.

Refer my sites: trunkbaseddevelopment.com/ and www.branchbyabstraction.com/