<< Tools Matter: Automated Builds / Automated Deployments | Home | Replacing Notepad With Notepad2 on Windows XP SP3 >>

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 @ Sunday, September 07, 2008 2:12 PM

Comments on this entry:

Gravatar # re: Do Not Store Environment Files in Source (i.e. config files) - Just Say No To Environment Files Period
by developingchris at 9/8/2008 3:51 PM
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.
Gravatar # re: Do Not Store Environment Files in Source (i.e. config files) - Just Say No To Environment Files Period
by Robz at 9/8/2008 6:10 PM
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.
Gravatar # re: Do Not Store Environment Files in Source (i.e. config files) - Just Say No To Environment Files Period
by Professor_k at 10/30/2008 10:46 AM
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.
Comments have been closed on this topic.