Hacker News Reader

IMO the main issue with this is that it means you'd have to patch the production version, and it might be different from the current (master/main/develop) branch, so you'd also need to backport your fix. Keeping configuration separate allows you to avoid that.

View on HN

If you're using Kubernetes / Argo then who cares. There's no backporting, there's only moving forward. If the configurable code in question is only ever used from such deployments then making the configuration static and compile-time makes some sense, and saves you having to write code that handles configuration at run-time. One might like to think that this sort of code might get run in other contexts too, so one might tend to prefer flexible, run-time configuration, but if you know that code will only run from deployments then you might as well not waste the effort on run-time configuration.

Releasing more often, keeping master/main/trunk deployable, and not having a develop branch or long lived feature branches solves a lot of that.

Of course that sometimes needs some kind of feature flags for bigger changes, which is a configuration option too, but at least the stable state of the code is simpler and not a nest of code + config that never really changes.

Reply on news.ycombinator.com