Fervent Coder

Coding Towards Utopia...by Rob Reynolds
posts - 278 , comments - 431 , trackbacks - 0

My Links


Rob Reynolds

Subscribe to Fervent Coder RSS
Subscribe to Fervent Coder by Email

About Me

I manage several open source projects. Need...
   ...package management for Windows?
   ...automated builds?
   ...database change management (migrations)?
   ...your application to check email?
   ...a monitoring utility?

I also write for

Like what you are reading? Want to buy me a cup of coffee?
PayPal - The safer, easier way to pay online!


Post Categories


Do Not Store Environment Files in Source (i.e. config files) - Just Say No To Environment Files Period

Environment files in source control are a big No No. Environment files are a big No No anywhere. Period. Except one place - where they are used. You should ONLY maintain ONE local environment file.  You should only store in source that one file that is needed to run the code locally.

If you have a config.DEV, config.TEST, config.PROD, etc. YOU ARE WRONG! Stop this, you are causing yourself more pain! Every time you update one value, you have to update it in several places. You are violating DRY (don't repeat yourself).

Well then, how do you get the files? You have to have them somewhere right? Yes you do. The answer to that is to either create them with your automated build script or to update your local file with the deployment script. One gives you the benefit of seeing them in the build folder (but adds additional work to the scripts to deploy the right one), the other gives you the benefit of updating the one file on the way out to the environment with less total build and deploy steps (but you have a point between build and deploy to verify that the script is working right before deployment). Either way, both of these are a better answer to less maintenance and pain.

I have experience with the pain of maintaining multiple environment files. I have experience with one answer.  I can tell you that if it saves time and is less prone to error, it is a better answer (but not necessarily the best answer).  And the better answer is the one you should choose 9 times out of 10 (because there is always an edge case).

In short, Just say NO! to environment files.

I have a post coming soon on how you do this with configuration files (or any XML file).  I will challenge you to the fact that you DO NOT need more than one file and that you can make changes on the way out.

Print | posted on Sunday, September 7, 2008 2:12 PM | Filed Under [ Code ]



# re: Do Not Store Environment Files in Source (i.e. config files) - Just Say No To Environment Files Period

In theory I agree with you. However, I have found that its better to have 1 file that has the globals, and a sub file that has the environments, then having continuous integration put them together. We use asp.net and mostly use this to fill in the connection strings file on a per environment basis, most other things in web.config are pretty static and should be kept dry.
9/8/2008 3:51 PM | developingchris

# re: Do Not Store Environment Files in Source (i.e. config files) - Just Say No To Environment Files Period

What about the local sub file? How does that work?

I would be curious to see how this works. It still seems like the files with the environments would be repetitious.
9/8/2008 6:10 PM | Robz

# re: Do Not Store Environment Files in Source (i.e. config files) - Just Say No To Environment Files Period

Still interesting in your solution, but here is mine.

My solution is to create *.template file for each file that has to be configured (for example - web.config.template), where all sensitive places are replaced with some tags looking something like ***MYTAGNAME*** and in separate place has to be files (I'm using xml, but it's your decision how to implement) with pairs of tag - value. They are also similar but contains only changing parts - e.g. connection strings. Each one for each environment.
Also there are in prebuild event to small selfwritten tool that searches for *.template files, and renames it into files without "template" extension, but with tags replaced with proper current environment values.

Also this event uses name of not existing neutlral file (for example - subst.xml, when there are no in folder with settings such file, but there are dev.subst.xml, test.subst.xml, live.subst.xml, etc.)
So developer after check-out have to rename file related to his current environment into neutral, else he'll receive compile error (and that's ok, because it ensures that he'll rename proper file).
Build script does this authomatically depending on target environment.

That does the job...
P.S. I'm using web application and web deployment projects for thsy.
10/30/2008 10:46 AM | Professor_k
Comments have been closed on this topic.

Powered by: