Question

I’ve currently got four XML files that are used to build my Dependency Injection container based on the environment my app is running on.

• base.xml is my default configuration that serves as a base for:
  • dev.xml which contains the overrides that apply to our local vagrant development environment
  • staging.xml which contains the overrides that apply to the testing/stating environment
  • production.xml which contains the overrides for the production servers

I’m not entirely sure that these files should be under version control along with the application code. All sensitive data is stored in a configuration file that’s ignored from the CVS so revealing sensitive data isn’t the issue. It’s rather that i’m not entirely certain that having an xml file under version control for each environment my app runs on is the way to go.

For example, we are considering splitting the staging and testing servers to that would mean an additional .xml configuration file would need to be created for the new server. And if we want to test on different systems (OS, web servers, databases, …) in the future this would probably mean we should create an .xml file for each system that it’s going to be tested on.

Am I just being paranoid or what is the general consensus on this matter?

Answer 1

I don’t understand why you wouldn’t keep you different environments’ configuration files under source control. I think it’s a generally good practice to keep configuration files in source control so that you’re not dependent on the files residing on someone’s system or a network share drive. Plus, if you ever need to revert back to an old version or check the history of something when suddenly everything breaks, having source control history is your reliable friend.

I think it’s in your best interest to source control those files, even if they never change.