On a web application project recently, I wanted to work myself out of the job of release coordinator. It’s a mundane, error prone and thankless task that needs to get done, a perfect job for a machine.

Our requirements:

  • Allow each environment to have different configuration values such as database connection strings.
  • Every check-in should be versioned, compiled, unit tested and, if tests pass, deployed to a smoke test environment.
  • Each versioned build can be migrated to other environments as testers deem them acceptable.

Team Foundation Server 2010 is our ALM tool and fortunately there are a number of capabilities built into it that fulfilled a number of our requirements. Unfortunately, there are a couple of other pieces required and a few moving parts that it took a while to understand. A look ahead at the preview documentation for TFS 2012 shows that much of the build and deploy model will stay the same so this information should remain useful for the foreseeable future.

In this series of posts I will assemble all the resources I found that helped me to meet our requirements.

  • Part One: Getting the lay of the land.
  • Part Two: Preparing the Project for Continuous Deploy
  • Part Three: Creating the Team Build for Continuous Deploy
  • Part Four: Performing Parameterized Deployments with Web Deploy

Two Cardinal Points: MSBuild and Web Deploy

I wandered too long in the jungle of Microsoft ALM before figuring this out, but when I did, it was a miniature revelation: There are two distinct sets of tooling to consider when fashioning a Continuous Deployment environment and they each supply distinct capabilities that are often muddled by the enablers inside of Visual Studio.

When we hit CTRL + SHIFT + B inside of Visual Studio, the MSBuild pipeline is what takes care of reading the csproj, vbproj or dbproj files in our solutions to do things like compile binaries, generate SQL deployment scripts and run unit tests. It also takes care of updating environment specific configurations through Web Config Transformations. MSBuild is the same pipeline that TFS uses when a Team Build is executed.

If you right click on a web project and click “Publish…” what’s being engaged behind the scenes is Web Deploy (formerly MSDeploy). This is a separate set of programs that use services hosted in IIS to update the application’s assets on the host machine. Web Deploy also has capabilities to delegate the rights to manage web applications so that the identity performing the deployment does not have to be granted administrative rights to the server.

To further muddy the picture, the package that gets deployed by Web Deploy is created by MSBuild. While this sounds confusing, it actually allows TFS to create the on-ramp to Continuous Deployment.

The Road Ahead

It’s important to keep the two cardinal points of MSBuild and Web Deploy distinct as we navigate, otherwise we will get lost. First, we will be setting up our project in Visual Studio 2010 so that the right settings are in place for MSBuild to use both on our local development box and also in TFS.

After that, we create a Continuous Integration build in TFS and modify the standard workflow to increment our application’s version number with every build before deploying it using the Web Deploy.

The final post in this series will show how to modify the project to enable Parameterized Deployments to new environments.