Grails: How we manage our configs at kaufDA/bonial

We at kaufDA/bonial have a lot of configuration parameter, we handle more then 5 countries in production and min. one staging systems per country and more then 20 developer configs. I will describe in this blog post how we manage our configs at kaufDA.

The grails configuration functionality is good, also the option to configure different environments. But what will happen if you will run your WAR on more then one stage environment with different databases or urls without building the WAR again, because the configuration are included in WAR. Or you will not have salesforces/mail server credentials in the normal git-repository where every developer have access. We have also configurations that are identical in every country (e.g. paths to file system) or in every environment by country (e.g. base location).

So we classified all existing configurations to the a category: final, country, local and environment.


This configuration is in every country and environment (production, stage & development) identical. e. g. url paths, pagination or starting time of jobs. Final configs could use variables from the country, local orĀ  environment configs. e. g. for the solr server the api endpoints are the same but the host are different.


Is in every country different but in the specific environment of the country identical. e. g. base location or displaying format of dates


Contains specific configurations for the running system, in production or staging this configs are generated via puppet, because puppet knows the current database server or credentials of salesforce. Developers have there own local configs for new features or different databases.


Only configs thats fit not in the other config. e. g. domain urls or logging properties. This configs could also generate by puppet, but we decide to have this configs for the transparent in the project.

The order of loading config is supposed to be like this

Comments are closed.