I am developing a C# windows service application, which have different configuration files for development, for production system, for test system, like:
Dev.config
Test.config
Prod.config
Now we are using SVN version control system, and configuration files stored in projects directories:
-trunk
-MyFooService
-Configs
Dev.config
Test.config
Prod.config
-MyFooService2
-Configs
Dev.config
Test.config
Prod.config
Prior publishing service to production you should get respective configuration file from that folders. How do you think, it is correct? Or configuration files should be placed in another repository? Or in another folder or should not be placed in VCS?
Or may be it will be better to place files like that:
-trunk
-src
-MyFooService
-MyFooService2
-configs
-MyFooService
-Configs
Dev.config
Test.config
Prod.config
-MyFooService2
-Configs
Dev.config
Test.config
Prod.config
What we’ve come up with is the following. We only place one config file under version control. It contains the settings of the development environment. It serves two purposes. One, if a developer opens a project and runs it, it should just work (see also the Joel test :)). Two, it serves as a template only. You shouldn’t actually store actual configuration settings in version control, but these are two very good reasons to make an exception with the development settings, out of necessity.
When we publish a project to a server, we never overwrite configuration files, we only merge changes into it if there were any. The problem you are facing is that environments can change all the time, you can add new environments or modify existing ones, and these environment changes may have nothing to do at all with your development cycle. Even more importantly, we have no control at all over the clients’ environments. Why would we want to store those settings in our version control? When we give a published project to our clients, we rename the config files to config.sample, they are forced to edit it according to their needs.
5
Building on @fejesjoco’s answer, one config only config for dev machines.
For the environments, I would store 1 file, like ServiceX.environments under source control.
During the deployment or build process, you could have a script create a configuration file based on the environment file passing which environment you want to create. For example, maybe you have integration, qa, performance for in house environments. It would read the environment file, locate the appropriate section, and then create a configuration file.
Then you have a consistent way to deploy config files across internal environments. It also doesn’t confuse developers with many config files in a solution. You still want the environment file under source control, but don’t mark it as a config, then if envronments change its just a update and check in.
As far a external customers or builds, you could have a step to create a config that is more or less a template for them. After that, they take the config and modify for thier own needs, but there is not need to store those under source control as the external customer should maintain them.