It’s very tempting to use a generic
isProd) flag in the configuration. For example, when
isDev is true, enable a hidden developer feature, add more verbose debug logging etc.
Lately I started to consider these
isProd flags as antipatterns. They are magnets for use cases. Everything goes well, until you hit an exception: for example, there are three production stages (alpha, beta, stable), and some developer tooling needs to be enabled in the dev builds and then only in the alpha build. Effectively pieces of the configuration start to spread into the app code, and checks like
isDev OR isAlpha start to appear. For the next engineer who’s going to work on this code it’s impossible to inspect the configuration without inspecting the code.
I think looking at the configuration should be enough for an engineer to understand what are the differences between the deployments.
Here’s a tip: instead of
IF isDev OR isAlpha THEN enableDebugLogging, add a specific field called
debugLoggingEnabled to the configuration, and set it to true for