This is the third part of a four-part series on using Team Foundation Server and Team Build to set up a continuous deployment environment.
- 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
In this post, we will walk through setting up the Build Definition that will deploy our solution to the target environment.
It is often the case that the TFS Build Controller running the build is missing some pieces necessary to perform a deployment from the build. The following steps describe how to prepare the build server for continuous deployment.
Configuration Transformation Support
The MSBuild targets for config transformation are not installed by default as a part of TFS. Copy C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web from a development machine to the same directory on the Build Controller machine.
Assembly Version Increment Support
There is an MSBuild Community Task project that enables updating version information during a build. Download the latest version here https://github.com/loresoft/msbuildtasks/ and copy it to C:\Program Files (x86)\MSBuild\MSBuildCommunityTasks.
IIS Web Deploy
The client-side tools of Microsoft’s Web Deploy (http://www.iis.net/WebDeploy) must be installed on the build machine that performs the deployment. Download the latest version, run it and follow the installation wizard instructions.
A script that runs during the build performs a checkout and update of a file containing version information. Doing so requires that the Team Foundation executable be present in the path. Copy the following files from a development machine onto the build machine:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\tf.exe
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\tf.exe.config
The Build Definition
When you create a new build definition, the “Default Workflow” will be selected. This Windows Workflow Foundation xaml file takes care of most of the basics required to compile code, run unit tests and drop packages to a the configured Drop Location. If that is all you need, then walk through the build properties…
Give your build a name and description.
Set the Trigger to Continuous Integration.
Point the Workspace to the root of the project you wish to build.
Set the drop location where you want the build to be staged in Build Defaults.
At this point the build definition is nearly complete. The missing pieces are all contained in the Process section of the build definition.
Items to Build Modifications
In the Items to Build settings you specify which project configuration will be built as well as the solution or project you wish to build. The configuration you choose should correspond to the one that you configured in Visual Studio (covered in part 2 of this series). In our case we want to deploy to the “Dev” environment so that is the one selected in the build definition. Doing so will ensure that the project properties for that configuration are used, as well as the configuration transformation we have set up.
Make sure that that Projects to Build setting points to your solution if you wish for all sub projects to be included in the build.
Whatever is entered into the MSBuild Arguments property will be passed in the call to MSBuild.exe during the build workflow. The following table describes the function of each parameter we use. Some of these values will have more meaning once we cover setting up IIS Web Deploy on the target server in the next post.
If you don’t need any special version numbering, your build definition is complete.
However, if you would like to synchronize your application version with the build stamp, further customization is required. The post found at http://blogs.msdn.com/b/jjameson/archive/2010/11/29/incrementing-the-assembly-version-for-each-build-in-tfs-2010.aspx details the modifications necessary.
At a high level you’ll be doing the following:
- Adding an AssemblyVersionInfo.cs file to your project that contains version information you want shared across the projects in your solution.
- Adding a bare bones MSBuild proj file that checks out the AssemblyVersionInfo.cs file, increments the number stored in it and checks it back in to source control.
- Creating a custom workflow based on the original Default Workflow that calls the new proj file, labels the source control workspace found in the newly incremented number and drops the build artifacts to a folder named for the new version.
At this point we have a build definition that will be triggered every time someone checks in a change to the project. If the build is successful, it will try to deploy that project to a web site, but it will fail. This is because we must still configure IIS Web Deploy on the target server to perform delegated deployments. We will cover this and setting up our projects for parameterized deployment to new environments in the next post.