I'm employee in IT company the offers a solution for many customers, there are about 100 sites build on the top of our product code and all of them are hosted in the company DC.

The thing is we have a long hierarchy of XML configurations that used for each site to set different variables that enable/disable features, pass values there and a lot of other usages, the hierarchy is something like the top parent one for default values of all XML, then another XML for the sites in specific env, then the site itself, (Actually it's longer than so).

We have customized registry module to read this config and hierarchy, each site query any config by using that module and passing XPATH for the aimed feature and assign it to variables there , but the problem is the config are getting increase more and more, for now the final set of config for most of the sites exceed 500 values, not to mentioned that any change on XML required the product to be restarted to get the config again be because they are loaded at initialization time.

I need to know if any other has faced this situation to know if there is a better solution to handle this since the tree of XML is very complicated right now and I need to come up with better solution,especially the DevOps team do that frequent configuration changes since the XML files for different env in the DC are DevOps responsibility.

Is there any existent tool for such problem?

If no, then I have an idea to do so.

My idea now is to separate the config to set of features each feature has its own json object with set of related values. Will take out the registry module from the product code and create nodejs API that the site read from its config for each feature. The API will let the developers create new feature json config and set the types of each value there. The AM will see the feature created by developers and set the config there to enable/disable or assign any other values there.

So for so good, but that is milestone change and it's in the platform level, so I need to know:

any has experienced this situation before and how they handled it if there was? Can anyone give me his opinion about what I proposed above?

closed as off-topic by Tensibai Apr 9 '18 at 21:36

  • This question does not appear to be about DevOps, within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • What did you find on the internet? – 030 Aug 7 '17 at 11:30
  • I'm voting to close this question as off-topic because it only brings opinions with no reference out of author and start gathering self promotion posts. This is too vague and open ended in my opinion. I someone want to discuss this closing further, feel free to open a discussion on DevOps Meta – Tensibai Apr 9 '18 at 21:36

Avoid writing custom code if there are existing tools that are already able to do this.

I would go for Ansible as is able to easily read and write json, yaml and xml and is also easy to use.

Ease of use is essential because it allows you to use junior staff too, otherwise you risk to end-up being overloaded.

Regarding API and so on.... sounds like feature creeping to me, something that sells well to managers but that was never proved to work as well in practice.

Configuration management stays very well in GIT, use review process to access changes and CI automation to test and apply it.


Config is a configuration file management tool that can help you. You will have the typical Dev, QA, Prod environments, and for your Prod environment, create 100 instances. You can start with the SaaS solution and you can grow into the on-premise setup. Config supports XML, JSON and other configuration file formats. It won't help your restart to reload issue, as that is something in your application you need to fix. I'm part of the team so feel free to ask questions.

Your developers can have access to the Dev environments and your devops have access to all environments. Synching common values and using environment variables are all core features. You have a history of all changes, can review them, and can deploy configuration files by version or tag. Yes, there is a deployment step, similar to pulling a file from Git.


It sounds to me like you have some serious architectural issues with the configuration of application. It sounds like 1) XML files or SOAP requests are a terrible way to manage configuration of an application and 2) the application is not very agile and requires a restart every time a change is needed, which is disruptive.

Using JSON is a far better way to manage the application configuration - especially if this change will allow the configuration to be dynamically updated without a restart using a REST API.

You will find that configuration management tools, whichever you use will require some integration coding - Ruby for Chef and Puppet or Python for SaltStack and Ansible - for the REST API calls.

While you could use something like Ansible to manage the XML files, this is not the best way to do this and will leave your application with several pain points. Rearchitecting your application in the manner described is definitely the right call.

  • I fail to see how switching from XML to JSON/YAML/Binary/whatever would do anything to help. – Newtopian Aug 8 '17 at 14:58
  • Clearly you have never used a SOAP api... It works especially poorly with a configuration management tool which is poorly suited to send SOAP calls - and in this case the OP has made it clear that his tool can't even be managed by SOAP calls - he is dealing with flat files and the application requires a restart. While making a SOAP api could help, the best solution would be to use JSON which is far easier and more intuitive to work with. – James Shewey Aug 8 '17 at 18:50
  • Neither the OP or I have mentioned SOAP anywhere so let's stop about what experience I may or may not have in this regards as it is completely off topic here. clearly the OP seems to have architectural issues with his solution this we can agree on. I still fail to see how the choice of file format will do anything to help him, a mess of XML files and a mess of JSON file is still a mess regardless. In fact if the XML mess has well structured XSD files that defines them I'm pretty sure just switching over to JSON you just made things worst. – Newtopian Aug 8 '17 at 19:02
  • @Newtopian *worse. You are again demonstrating your inexperience with the subject matter. SOAP is an XML based Web API. REST is a JSON Web API. I have coded with both. One sucks and is painful to work with. Most vendors are deprecating any SOAP apis in favor of REST. In order to ditch the restarts, the OP will need to use something dynamic that can be interacted with at runtime - an API like SOAP or REST so this is wholly relevant and on topic. The temptation would be to recycle your existing XML parser for that. But that is the wrong move: SOAP is a pain. – James Shewey Aug 8 '17 at 19:54
  • you have an unhealthy fixation on SOAP. If you read carefully the OP's question and my comment you will notice that you are the only one talking about SOAP here. – Newtopian Aug 8 '17 at 21:56

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