3 ms·

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) branc

• chikere232 2y ago
  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.
• cryptonector 2y ago
  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.