What should be the strategy to migrate configuration files to new version?

Question

I understand this is question is completely implementation dependent, but would like to know the general strategy used to migrate the configuration files.

We have a product that reads some configurations from properties/XML files. Some default values are configured in the properties file. Customer can change the properties as per his needs. Now suppose we change/add some properties in the file and customer migrates to newer version. How should we merge the customer specific configuration with newly added/updated properties? One way is to write a utility to merge the files, but dont want to do it for every release.

Thanks in advance

Personally what I'd do is to temporarily store/sync a copy of the configurations in a database and then populate the newly adjusted/changed configurations when deploying the new release. — Ceiling Gecko, Jan 28 '14 at 10:29
@sidgate to me changing the props that the application reads is like changing the api, there is no easy way to handle this. I would write a simple utility for this, but this is sooooo dependent on the type of app and what the props actually change/introduce.. — Eugene, Feb 26 '14 at 14:05

score 2 · Accepted Answer · answered Feb 27 '14 at 21:03

We have a configuration inheritance schema. Within development we have:

BaseSetup <- Setup <- DevelopmentSetup <-- StagingSystemSetup
                                        |- DeveloperMikeSetup
                                        |- DeveloperSusySetup

So the demonstration server runs with the setup StagingSystemSetup which inherits from the general DevelopmentSetup, etc. Also each developer has its own configuration/setup, which is also checked in. This means everybody can change its configuration as needed, without interfering others.

On production/customer just the setup is used without specialication, but that is the setup provided by the customer, which inherits from the basic setup.

If we introduce and enable a new feature we only need to modify the base setup. Ideally, forced setup changes by the customer should not happen.

That looks useful. I need to check whether commons-config provides a way to maintain the inheritance, and whether we can merge those. — sidgate, Feb 28 '14 at 09:39
I was expecting more alternatives, but looks like this is the better to go ahead. — sidgate, Mar 03 '14 at 10:48

score 1 · Answer 2 · answered Feb 26 '14 at 14:27

I'd say it's all documentation. I won't bother with a migration tool. You surely have documentation of your software. Include the configuration changes in that documentation. It's the responsibility of your customer to read the change log and apply those configuration changes. If a missing new configuration is essential and has no reasonable default value the error message should clearly point the customer to the missing configuration. OTH if the missing configuration has a default value a warning in the log might be helpful.

What should be the strategy to migrate configuration files to new version?

2 Answers2