Blog / Software Delivery

The poor man's feature flag

How to use feature flags if you don't have feature flags.

I recently had a chat with a developer whose team had recently made the switch from GitFlow to trunk-based development. He observed that long-lived features were painful in trunk-based development, due to the lack of feature flags.

While there are many great feature flag frameworks and tools out there, you don’t need to wait for your team to implement one to start using feature flags. You can start today with the poor man’s feature flag:

if (false) {

Yeah, that’s it.

Wrap your new, incomplete feature in a simple if (false) conditional, and merge it into master as normal.

Any unit tests you’ve written will still run and execute your new code—it just won’t be exposed in production builds. Perfect!

When you’re working on it locally, just change if (false) to if (true), and hack away. And when the feature is finally complete, delete the conditional entirely.

If you found this message interesting, I expand on the topic of feature flags in my free What is Continuous Integration email series.

Share this

Related Content

A merge a day keeps the conflicts away

Merge a minimum of one PR each day. Make small PRs. Don't worry if the feature is incomplete, only that each PR works.

These Days Proper CI is Table Stakes

There is a lot of variety when it comes to Continuous Integration and Continuous Deployment (CI/CD) configurations. But I am constantly amazed by how many projects fail to even implement the absolute minimum CI configuration. In this article, I outline what I believe to be the absolute, bare minimum automated continuous integration tests that should exist on practically every project. These are table stakes. You ought to be embarrassed if your project doesn’t do these things.

Are you doing CI/CD?

It's not continuous deployment if you aren't deploying... continuously.