Managing differences in configuration across deployment environments

A common problem when writing applications is to manage differences in configuration across deployment environments.

That sounds like a mouth-full, allow me to illustrate using the following example:

If you are writing software that needs to connect to a database (or other external resource), the connectionstring for this database is typically stored in a configuration file.
Throughout the development cycle of the application, you might have to be deployed to different environments:

• The environment used to develop the application.
  
• Perhaps an environment in which acceptance tests are done on a new release.
  
• Eventually the environment that is used to take the application in production.
  

Unless development is done against the same database that is used to run and test the application you will have to modify the connectionstring for the database that contains the data.
Realistically, the configuration file might contain a number of settings that differ from environment to environment and others that might never change.

Keeping track of what to change for which environment becomes a challenge.

Previously

Previously I wrote a feature for Enterprise Library which was called Environmental Overrides, which keeps track of the differences in configuration for each deployment environment.
However, this solution only works for configuration managed by the Enterprise Library configuration editor.

Recently I decided to have another stab at the problem and started writing a visual studio package that allows doing the same for arbitrary configuration files.
The design for this package is fairly simple and seems to work quite well. I uploaded an executable prototype of this package to my codegallery which allows you to play around with it.

How Environmental Overrides works

Environmental Overrides allows you to right-click a configuration file (anything with the extension .config) and add a copy of this file "underneath" the original in visual studio. The file you add is a configuration file that will contain the configuration for a specific environment (ex: test or deployment environment). You can add as many files as you which, and these I call "environmental configuration files". The original configuration I will refer to as "master configuration file".

To modify an environmental configuration file, open the file in visual studio and make any number of changes for this specific environment.

When the master configuration is opened in visual studio, Environmental Overrides will create an in-memory copy of the master and keep this laying around in case you which to modify the master configuration file.
If the master configuration file is modified and a new version is saved, Environmental Overrides will compare each of the environmental configuration files with the original copy of the master configuration file, which results in a set of differences.
For each of the different environments a new configuration file is composed by applying the set of differences to the modified master configuration file and the resulting configuration is stored in each of the environmental configuration files.

Keeping track of the differences

Another "featurette" I added is the possibility to compare 2 configuration files and highlight the differences. Right click the environmental configuration file and choose the "Highlight Environment Differences". This will open both files and display modified, added and removed settings in respectively gray, green and red:

Deploying configuration to different environments

Environmental Overrides doesn't help you deploy the different configuration files to different environments, it helps you keep track of changes.

Useful information on deploying configuration files to different environments can be found at Scott Hanselmans blog: Managing Multiple Configuration File Environments with Pre-Build Events

Before you download and install the *prototype*

Please keep in mind this is a prototype, which means its purpose is to demonstrate a concept, not to release something feature complete.

More specifically:

• I have tested this prototype on a couple of scenarios but: It might well screw up your configuration files.
  
• It has no workflow for configuration files that do not contain valid XML and wouldn't propagate changes.
  
• It doesn't integrate with sourcecode control providers (it doesn't check out files).
  
• It doesn't work with the new type of web-projects.
  

None of the things above are significant improvements.
But with this prototype I would like to gather feedback then move toward something you might consider using every day.

Download the prototype from code gallery.
Voice your opinions over at my Issue tracker.

Thanks