3 ways to automate configuration

Manual Configuration

Manual configuration is the most popular – but this leads to repetition for us humans and unrepeatability of the resulting tool state. So we want to automate the configuration of a tool. What approach should we take?

The 3 Ways to Automate Configuration

There are 3 main ways to automate configuration.

  1. manually configure and then copy and paste the backend configuration files
  2. via a web services (rest) api – make api calls to create and update the configuration elements
  3. surgical – identify config end points and deftly change specific files and folders

1. Copy-all and Paste can be problematic

The strategy is to perform the configuration changes (usually through the application’s gui (graphical interface) and then copy and paste the backend configuration files and version control them to make them accessible in the future and for others.

Examples are copying configuration from the Google Chrome browser, the IntelliJ IDE, the Apache2 WebServer.

This one size fits all seems simple but it is not a good idea in some circumstances. The problems that can manifest are as follows

1. After an upgrade your large configuration bucket can be immediately invalidated. To fix this you would need to manually make the configuration changes again (if you know them – you may not have even done them – it could have been done by a teammate).

2. When collaborating with others – this copy-all strategy would fail if certain config elements like absolute paths would not apply to others. You could copy/paste then change but this can be compounded with the “upgrade” scenario – and this strategy becomes too unwieldy to maintain.

2. Web Services API Configuration

Tools like Jenkins, WordPress, VirtualBox, MongoDB and MediaWiki now provide an API for configuration.

If your middleware or your client based software app provides an API for configuration – that may be a good option. It protects against upgrade – so if the tool changes from XML to YAML the REST API would still remain a constant.

The problem with this approach is either the unavailability of such an API (for example for WordPress). It is only now that WordPress have launched a REST API for configuration and submitting posts.

The learning curve of such API’s remains a barrier to their adoption. Sometimes it simply does not warrant the effort.

3. Surgically Change the Configuration

This approach is often taken when configuring MySQL, MongoDB, Subversion and Tomcat.

This approach requires a lot of knowledge of the configuration file formats. But it is a lightweight approach if you want to make just a handful of configuration changes.

Of course this approach is also affected by an upgrade – but if the number of “significantly” different configurations to apply is low – it can be a rewarding approach that is maintainable and useful even when collaborating within large teams.

If binary “unopenable” formats are used (also known as closed configuration) – this slice and dice approach is thwarted and you may need to recourse back to the above options.


The choice generally boils down to three key considerations.

  1. the amount of configuration that needs to be applied
  2. balancing learning back-end file formats or learning the API
  3. visibility of the backend config files vs availability of an API

Leave a Reply

Your email address will not be published. Required fields are marked *