2

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
| improve this question | |
7

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.

| improve this answer | |
  • Actually it is our internal service, and configuration files changes rarely. Then the question is where to store actual configuration files? :) – Alexanderius Jan 8 '14 at 9:06
  • 1
    We store them on the servers only where they belong, inside the application folder. The idea is that an environment-specific configuration file should reside in the environment that it describes, the outside world doesn't care about the insides of an environment. – fejesjoco Jan 8 '14 at 9:10
  • 1
    @Alexanderius: Configurations changes rarely, but when they do, you always need to use current configuration even for old versions. So the configuration should be stored in the environment it describes. – Jan Hudec Jan 8 '14 at 9:12
  • Where you keep the backups of that files? – Alexanderius Jan 8 '14 at 9:13
  • 2
    We backup our entire servers with DPM. You have no use of a configuration file backup if the environment itself is dead... – fejesjoco Jan 8 '14 at 9:14
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.