I have being thinking about configurations and who they are used by. It is a user that uses a configuration, but who is the user? This is not talking about what settings a user should be allowed to configure but how the user configures those settings. The blog post Good Configurations has some of the seeds for the ideas outlined here.
If your deploying a website there is going to be configuration choices that you the system administrator is going to have to think about. One example is how many replicas of the service is going to be running. Of course you could hard code these values some where or then could be put into configuration files. In this case are you the administrator the user or is it the actual web site deployment that is the user? We the administrator gives the configuration to the web site, so I think in this case the web site is the user. The end users which use the web site has no say or care about these configurations.
When is the end user the user of a configuration? I think this is when it has an effect on the end user. The example here is the desktop wallpaper is configured by the end user to their liking. While the operating system mostly does not care what the wallpaper is for it to do it's job. In this case the configuration is personal to the end user so they are the user of the configuration. Being called a consumer might be a better term for the use of the configuration.
There seems to be a third type. That is the creators of the applications, the developers. These fall into a gray area. Yes they can be working on a web site which in the finished product the application is the configuration user. At the same time the developers can be working on the operating system that allows the user to set the wallpapers.
It is these different scenarios that has got me thinking about this problem. For the end user configuration settings we as the providers of the application should try give good default configuration settings out of the box. But at the same time during the development cycle we as the developers need to be able to change these settings quickly for development testing and such. Same it true for applications where it is the application that is the user of the configuration.
We should also take into account that an application many have many configuration settings. Which all need to be accessible by the developer. But in the same breath they don't need to or should not need to configure all setting every time. This tells us we need a way to introduce a subset of configuration into the main configuration. This idea of having a subset allows for some interesting out ideas.
Lets step back and look at what we have. Our application has a main configuration file. These configurations can be updated within the application by a secondary configuration file. Developers now have an easier way to adjust just a few settings but so does everyone else. The administrator can have a subset configuration file that they load in the web deployments. This could be stored in version control and makes it clear what about the default configuration is being changed. Depending on how the end user interacts with the configuration files they too can have a smaller subset of settings that now could be moved between systems.
From the development side, it becomes easier for the team to share configurations between each other. This can be super helpfully when a new member is starting to work within a different area of the application. Many applications will use pipelines to test the application. These pipelines would put an application into a state for testings. This could mean changing some of the configuration of the application. When this can be configured using a subset of settings it simplifies the pipeline design but it also means a developer can reproduces the deployment faster if needs must.
The next question that we should be asking is how to we achieve this and also what exactly are we trying to achieve. I think what we are trying to achieve is a way for an application to load two sets of configuration files where primary configuration is the user set configuration and the fallback is the default settings. In the application we want to load the fallback configuration first and then load the primary which will update the configuration.
The location of the fallback configuration file will be know but what of the primary configuration file. That might not be known. My first thought was to have this as a hard coded value in the application but that is just silly. It should be placed as an entry in the fallback configuration. However we would want to ensure that if the user adds that field to the primary configuration it is ignored. While this is all good and well, as a developer I know there is a high chance I would have many primary configurations for testing different configurations. For this reason I think a environment variable should be allowed to be set which points to the location of the primary configuration. When the environment variable is set that should only be used and any primary configuration file stated in the fallback configuration should be ignored.
