I have inherited a distributed application with a lot of legacy configuration management.

Currently the application does not get it's settings updated with an application update. The flow looks something like this:

  1. The application is updated. The only settings that are defined are one's with hard-coded defaults.
  2. A separate workflow pushes a configuration to correct the application state from a separately maintained "gold" config.
  3. A user may manually change settings on the application.
  4. A user may request the workflow from 2 be re-run with some setting change.

Because the application is running at a scale for 3000+ instances, manually doing anything is very error-prone so we have another workflow that detects any setting that is drifted from it's "gold" value.

To lower the complexity, I have suggested we move the "gold" config into the repo and evaluate it at build time.

I've had a few holes poked in that but it feels like the right direction. Specifically other stakeholders are worried that we would introduce a setting regression on a hotfix.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.