Use Flexible Feature Flags

In my last post, Stop Hitting Yourself, I described (long-lived) branching in version control as an anti-pattern. It’s something we want to avoid.

But then what are the alternatives to branching for integrating code as it’s being built into a production system? We can’t let half-baked features slip out into production. If we do, the users will try to access those features and they will fail.

We want to integrate code as it’s being built so we can get immediate feedback if our code is causing any problems in the system. If we build code in its own branch, then we’re shutting out that feedback until the branch gets integrated into a trunk, which often happens too late.

Instead of branching, we can use flexible feature flags. The feature flag is simply a Boolean whose state determines if a feature is under development or ready for production. If a feature is under-developed then it is excluded from the UI so the user cannot gain access to it but it’s still a part of the build. So the code under development gets built with the rest of the system and we can be alerted if there are any issues.

Once the feature is ready for production we can either flip the feature flag or remove the conditional entirely.

There are several ways to implement feature flags. Straightforward conditional logic is my favorite approach. Avoid using conditional compiles because the whole point of using feature flags is to include work under development in the compile, but just don’t let it be accessible in production.

This is a simple solution to a major issue but you know what Occam once said: the simplest explanation is usually the right one.