Should appsettings.Development.json be added to the repository?

Question

Lately I got in a discussion with my colleague whether the appsettings.Development.json should be added to the git repository or not.

My considerations are: when a developer clones a repository to his development machine and builds the application, he should be able to run the application without any tweaking of the settings. That's what the appsettings.Development.json file is for: providing settings for a Development machine, so the application can be executed, tested (and debugged) locally.

However, the questioned appsettings.Development.json contained some absolute paths to files, which is bad because not every developer uses the same directory structure on his machine. So, there is still some tweaking needed before the application can be executed. My colleague uses this as an argument that the appsettings.Development.json should not be added to the git repository and that every developer should create his own appsettings.Development.json file by looking at the appsettings.json and replacing the values in that file as needed.

(Both the appsettings.Development.json and the appsettings.json do not contain any security data or passwords; the first one because it has only development settings and the second one only contains tokens that must be replaced during deployment.)

On the internet, there was almost nothing to find about this subject. So my question is: should the appsettings.Development.json be in the repository or not?

Answer 1

when a developer clones a repository to his development machine and builds the application, he should be able to run the application without any tweaking of the settings

In an ideal world, it would indeed be the case. Moreover, some open source projects, including very large and complex ones, are exactly like that: you check out the source, you run make, and it works flawlessly.

This, however, requires a lot of effort from the maintainers. Such effort makes sense for open source projects, where a lot of persons are checking out the project for the first time. If you don't automate this stage, those new persons will create tickets that will waste maintainers' time, and create an overall feeling that the project is not mature enough.

In corporate projects, things are different. You may have a new person joining the team once per year, and it's simply cheaper to just spend half an hour with this person configuring his environment and making the whole thing work. The steps to make it work may be documented, but not necessarily automated.

Moreover, some steps cannot be automated easily. If the project relies on, say, the corporate message queue service, and in order to gain access to it, you need to create a ticket for the support team to grant you the permissions, the step is necessarily manual.

However, the questioned appsettings.Development.json contained some absolute paths to files, which is bad because not every developer uses the same directory structure on his machine.

Or maybe what is bad is the fact that every developer uses different directories. The benefit of a corporate environment is that you can automate the deployment of a new operating system and all the required software to a PC of a new employee. Once you do it, everyone would necessarily have the exact same directory structure.

the appsettings.Development.json should not be added to the git repository and that every developer should create his own appsettings.Development.json file by looking at the appsettings.json and replacing the values in that file as needed.

When somebody joins the team, it is indeed relatively easy to customize the settings, if things are properly documented. However, once you customized the settings, you should check your changes to the repository, in case you delete the settings file by mistake (or your PC takes fire).

One of the possible approaches that I've used for my Python projects is to have a general config.json file containing the recommended settings, and then config.<machine-name>.json file containing the settings specific for a given machine. At runtime, the application checks both files, and deduces the actual settings that need to be used.

Answer 2

There's a situational case to be made for either approach.

I generally side with you here, but it's the use of absolute paths that's mostly the issue here. Using absolute paths directly negates the ability to have the same codebase work on different machines.

If the absolute paths are unavoidable, you can't really have a working dev config anyway. It's generally easier to just not check it in then, to prevent multiple developers forgetting to ignore the file and overwriting it constantly.

But I do agree that when you have the option, it's much more preferable to not have absolute paths to begin with, which would enable your "execution ready" dev config file to be stored in the repository.