This post describes the process that we use on our current ASP.NET MVC application to deploy our database and web application to a development environment as part of the nightly build. We use Team Foundation Server (TFS) 2010.
What we tried first
When we first set this up, we did it by passing in a bizarre and poorly documented string of MSBuild arguments as part of our build process. This approach is described by this stackoverflow questionand this PDF talk.
Here you can see the MSBuild arguments in our build definition. The arguments will vary depending on your own setup so I won’t copy all of our arguments in.
This worked great …. except that it deployed our application even if tests failed since it’s part of the build process. When the code was compiled, the application was deployed. This was problematic since it meant a broken version of the site was deployed to the development environment in the unlikely event that the nightly build broke.
The new approach
To get around this, we had to change our build process to run the deployment only if the tests passed. This meant customizing a build process template.
Editing the build process template
Every build definition is based on a build process template. By default, they’re based on “DefaultTemplate.xaml”. The build process templates are stored in a folder called “BuildProcessTemplates” that lives in the root of your source control folder. There are three in there with each new project
- DefaultTemplate.xaml
- LabDefaultTemplate.xaml
- UpgradeTemplate.xaml
Our previous build was using DefaultTemplate.xaml so we made a copy of that one. Editing the file opens up the Windows Workflow designer surface.
To get something to run only if tests pass, you’ll be interested in opening up the following sections of the template. Be prepared, because you’re going to have to dig deep. It can help a little to double-click each section – this will make the designer zoom to that section and hide all the others.
- Run On Agent
- Try Compile, Test, and Associate Changesets and Work Items
- Sequence
- Compile, Test, and Associate Changesets and Work Items
- Try Compile and Test
- Compile and Test
Here’s what it will look like when you get Compile and Test opened.
Adding a new action to the build template
Notice the conditional “If TestStatus = Unknown”. This evaluates to true if the tests pass or if there are no tests. In our case, this was exactly what we’re looking for. We wanted to deploy our application if the tests pass and not do anything if the tests failed.
I copied the “If TestStatus = Unknown” action and made another one just like it as a starting point for our custom build action. You can see it in the picture below. It’s prefixed with “(CUSTOM)” to make it easily distinguished from the regular build stuff.
In this conditional, we added three steps. Two to deploy the database and one to deploy the application.
The database deployment is just an executable that runs our DDL scripts and then uses EF to fill up the database with its initial data. Nothing fancy.
The “Deploy to DEV site” action is an MSBUILD action that has all of the goofy parameters that were previously part of our build parameters (See “What we tried first” above.). When this runs, the code gets compiled again and the application is deployed.
Future improvement
One thing that’s not ideal about this approach is that the code is compiled twice. It’s compiled once as part of the normal build and then it’s compiled once more when we run our custom workflow action. Ideally, we would call webdeploy manually instead of calling it through MSBUILD. This would deploy the application without building it again. But that’s a problem for another day.
More resources