.Net Release Management (Part 1)

Over the last few days at work we have been exploring the idea of how to make our release process more successful.  I have to admit that I haven’t really explore this much, so I spent some time researching what options were available for .net web application deployments.  I am earnestly surprised by the answers I have found… both for the good and bad.  Since this is a large-ish topic, I am going to break this up into multiple posts.

MSBuild

The first, and most powerful tool, in taking ownership of your release process is better understanding MSBuild.  If you are coming from the Java world, there are a few tools (Maven, Ant) which help people take control over their build.  These tools are generally XML files which offer additional build options, conditionals and tasks.  MSBuild is Microsoft’s offering which is very similar to those tools.

In order to get started with MSBuild you have to unload the project (not remove) and then right click on it again to see a “Open Project File” dialog.  That file you open is your MSBuild xml file.  MSBuild is broken apart by sections (build targets (DEBUG, RELEASE, etc..)), events (POST-BUILD, PRE-BUILD, etc..) and then by tasks.  By default MSBuild includes things like copying files to specific locations, creating folders, deleting folders, etc… these tasks can be further extended through customization.  See here for more information.  There are also prebuilt a collection of tasks for public consumption.  Some of these include:

If those don’t suite your needs, you can always build your own custom task.  Using these tools and taking advantage of the build script, one could do a great deal more inside of the build process to create a far more controlled release process.

Web Deployment projects.

Websites, by default, don’t contain MSBuild (Unless you use a web application project).  The Web deployment project is a solution to help meet that need.  In addition to giving you MSBuild, Web deployment project also offers; web.configuration merging on build (great for environment specific settings), more pre-compilation options (how the .dlls are distributed), delayed signing automation, and even some IIS integration on build.

Install Msi’s

More Reading

Post build, you can use a web setup project to hook up your output from the web deployment project.  This helps with the precompiling needed for a release msi.

Configuration management

Everyone who works on asp.net websites should be familiar with the web.config.  This file contains all of the major configuration settings for how the asp.net site works including; registered assemblies, connection strings, application settings (and appSettings), and handlers.  What some folks don’t know is that some of these sections can be externalized into another file.  This is important because some settings are highly dependant on the environment they are running in.  What happens, at least in most places I have been, is that we solve this problem by creating 3 different web.configs and shipping the environment specific web config with the bits needed.  While this works to some degree, it’s highly prone to problems.  However, by using external files for environment settings you can abstract away most of those dependencies.  This allows you to make global changes (http handlers, modules, assembly refs, etc..) without having to rebuild and merge all three documents.  By just replacing the new web.config with the changes, none of the external files have to be modified.

There are two settings in particular that allow for the external file merging, configSource and file.  With the file setting, you can have internal AND external settings.  With configSource, your settings must come entirely from the external file.  Otherwise it will throw an exception at runtime.  Not all settings have a external source merging option.  In this case, you are required to take advantage of the asp.net configuration hierarchy.

Also, as an aside, the web deployment project also have some web configuration merge options that are worth exploring.

Web.Config merge hierarchy

Another thing generally not taken advantage of is the overall merge hierarchy of asp.net’s configuration files.  In short, when ASP.NET starts an application it merges from a variety of places to build out the total settings for the app.  This is done for a few reasons but notably it offers better security (some things can be placed in the machine.config and are less apt to be accessed) and for global settings for projects (machine.config is also good for that).  The merge process is basically machine.confg -> web.config (in config section) -> web.config (Inet root) -> web.config (Virtual folder) -> web.config (in sub folders)

You can move global settings around where they make sense, or release managers might take advantage of location tags to put various settings at a lower level then the virtual root for more control.  You can override some things, you can’t override others.  This is important because not all settings can have external sources by default.  In this case you HAVE to take advantage of the merge process to allow them to be abstracted away from your main config to allow for more flexibility in the overall configuration.

In my next post I will be talking more about continuous integration and general release management.  I am working on a phased approach to fully automating our release cycle.  I will share my findings here for all.

Advertisements
Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: