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

__ComObject Debug Visualizer

When debugging applications it is often useful to be able to browse members of types and explore an API at runtime. For managed types, this can be done through debugging tooltips. However when using an API that uses COM objects, debugging tooltips show little information. One API I know that relies heavily on COM is Visual Studio's extensibility API, and it's a pain to have to guess which objects are returned by what API call.

To ease the pain, I wrote a __ComObject debug visualizer; a debugger extension that displays the outline of a COM object. In the screenshot below you can see what the Visual Studio debugger would display when inspecting a COM object and the outline of the same object as shown by the debug visualizer.

(click for a larger image)

This debug visualizer is an initial stab at the problem and still a very basic implementation. It only shows the outline of a COM object. The visualizer doesn't allow to inspect property values or show the outline of their types. There is plenty of room for improvement, I already added some proposed features to my Issue tracker at code gallery.

If you want to give this debug visualizer a try: download it from the code gallery.

Hello World!

Hi all ~ welcome to this weblog!

About this weblog

This weblog is used to publish ideas around developer experience and the Visual Studio IDE. Some of these ideas will be expressed in writing; other will be available as executable prototypes.

Whether the ideas presented on this weblog are useful is up to you! Feel free to leave comments or send me email.

About the blogger

I'm an independent software developer/ coach and architect based in The Netherlands.

• In the role of software developer my main goal is to write "good software".
  
• In the role of development coach my main goal is to transfer knowledge about how "good software" is made.
  
• In the role of software architect my main goal is to define what "good software" means in a specific context.
  

In recent years, I've grown passionate about writing extensions to Visual Studio and every once in a while I find myself playing around with different ideas and concepts just for the fun of it.

A more effective development environment

Developers use a variety of different tools and methods to be more successful in their work. Some popular methods that make software developers write better software are:

• Standardization and consistency in how software is written.
  
• The adoption of a process that advocates pragmatism and good design.
  
• Utilizing proven frameworks, components or template solutions.
  
• Writing software in higher level programming (or modeling) languages.
  

There are plenty of solutions in any of the categories above. However - at the end of a day - adopting any of them is a game played in-between software developer and development environment. This is why this weblog is about encapsulating useful practices within the development environment.

Beyond this weblog

As I hinted before, "good software" means different things in different environments. The concepts on this weblog can only be about generic software development challenges. This inherently means that they can only be mildly useful within any specific environment or organization.

Whether you need help developing productivity tools specific to your environment or would like to assess what could be gained, contact me at VSPimp@gmail.com and either I or someone in my network would be able to help you.