1

There is a string field x, contains value a/b/c/d The order of a/b/c/d is changed infrequently , only once a year or several years.

What is the best approach to store this config? Currently , it's being put in config file and there is discrepancy between prod config file and source control.

edit 1 : I didn't share my thought to leave the option open. For me, this case fall in gray area where it's hard to tell whether this should be in code or configuration file or something better. As some suggest that it should be roll out from source control-> With this route, then it is not supposed to be in configuration file, but then there should be a new build every year or couple of year and I am not really sure if it worth the effort.

Improve this question
4
  • Why does it change in PRO and not in the SCM? How do you change it? Straightforward in production and manually? A UI?
    – Laiv
    Jun 13 at 6:36
  • @Laiv "Straightforward in production and manually?" yes. but if change is roll out from SCM , then no point putting it in config file.
    – hieu.do
    Jun 13 at 7:21
  • 1
    @hieu.do What are you looking to achieve with configuration if the value must always be the same in all environments? In general, the point of configuration is to be able to switch to different values as part of deployment and environment set-up, so that different environments can have different values (For example, URLs to external APIs, database connection strings, API credentials, etc.). If the value you're storing needs to be consistent in all environments then it's not really configuration, but part of the software artefact itself.
    – Ben Cottrell
    Jun 13 at 7:31
  • @BenCottrell it's a config for string display. yeah I am leaning on the option it might be better be moved code, yet still not completely sold on it. was wonder if there's any better/intuitive option
    – hieu.do
    Jun 14 at 8:35

2 Answers 2

Reset to default
3

Changing content directly on production is considered (by all means) a bad practice.

A better one would be to add this file to the SCM and roll out changes from there1.

This might take you to automate the rollout by tracking changes on this file, but it should be doable with today's SCM and CI/CD tools. Given your system seems to support external config files, the rollout might deploy the file only instead of the whole application.

One way or another, consider testing changes in a test environment first and don't release the file in production unless all tests pass successfully.

1: Or a Configuration Management System capable of tracking changes

Improve this answer
1

Assign versions.

Call the current code something like v0. It uses the order v0/a/b/c/d (four slashes), and if only three slashes are found then we treat it as implicitly starting with v0/.

When you change the order, bump the version prefix to v1 or v2. Code in the develop branch and code deployed in prod will either know how to cope with a given version, or not. In which case it can reliably bail out with a diagnostic.

What have we gained? There is no ambiguity, no chance of code treating a new a/c/b/d order as though it were an old-fashioned a/b/c/d config. You would much rather get an error than an incorrectly processed result which claims to be trustworthy.

Improve this answer

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.