Technology Toolbox

Your technology Sherpa for the Microsoft platform

Jeremy Jameson - Founder and Principal



Automated Deployments to DEV from the Latest Build Folder

This post originally appeared on my MSDN blog:

Since I no longer work for Microsoft, I have copied it here in case that blog ever goes away.

Last month I wrote a post detailing how to increment the assembly version for each build. However, incrementing the assembing version is only part of my recommended build and deployment process.

The following figure illustrates how deployments to the Development environment (DEV) are automated using the "latest" folder from the Builds share on the Release Server.

Automated deployment to DEV using the "latest" folder
Figure 1: Automated deployment to DEV using the "latest" folder
At some point since I created my Build and Deployment slide in PowerPoint years ago, I started naming the folder _latest instead of Latest (so that, by default, it appears above all of the version folders in Windows Explorer).

The _latest folder greatly simplifies the automated deployment process by:

  • Eliminating the need to determine which version (folder) to install from when deploying to DEV
  • Avoiding the need to detect a broken build and abort the deployment

If a build is broken (for example, a developer checks in code that doesn't compile) then the automated deployment process deploys the build as usual, except that the _latest folder contains the last good build (not the broken build).

To copy the build to the _latest folder, I add a custom target to the TFSBuild.proj file:

  <Target Name="CopyBuildToLatestFolder">
    <CreateItem Include="$(DropLocation)\$(BuildNumber)\**\*.*" >
      <Output TaskParameter="Include" ItemName="FilesToCopy"/>
    <RemoveDir Directories="$(DropLocation)\_latest" />

Then I override the AfterDropBuild target to invoke the custom target -- but only if the build was successful:

  <!-- After dropping a successful build, copy it to the "_latest" folder. -->
  <Target Name="AfterDropBuild"
    Condition=" '$(IsDesktopBuild)' != 'true' ">
      <Output TaskParameter="CompilationSuccess" PropertyName="BuildCompilationSuccess" />

    <CallTarget Targets="CopyBuildToLatestFolder"
      Condition=" '$(BuildCompilationSuccess)' == 'True' "/>

Some people deploy their solution as part of the build process (in other words, they'll put some deployment steps in their MSBuild file). However, I like to keep the build and deployment pieces separate.

To be honest, in all the years that I've been using this automated build and deployment process, I've used nothing more than a simple scheduled task to deploy the solution (using the out-of-the-box Task Scheduler in Windows).

For example, on the current project that I am working on, I created a scheduled task on the DEV server (named something like Install Fabrikam Portal - Latest Build) that runs every night (shortly after the daily build process completes). [Note that the client name has been replaced to protect the innocent ;-) ]

The first step (i.e. action) in the scheduled task rebuilds a custom database for the solution:

  • Program/script: "C:\NotBackedUp\Builds\Fabrikam\Portal\_latest\BusinessModel\Database\Deployment\Rebuild Database.cmd"
  • Arguments: > "C:\NotBackedUp\Rebuild Database - DEV.log" 2>&1
  • Start in: C:\NotBackedUp\Builds\Fabrikam\Portal\_latest\BusinessModel\Database\Deployment

The second step in the scheduled task redeploys all of the custom SharePoint WSPs and features for the solution:

  • Program/script: "C:\NotBackedUp\Builds\Fabrikam\Portal\_latest\Portal\DeploymentFiles\Scripts\Redeploy Features.cmd"
  • Arguments: > "C:\NotBackedUp\Redeploy Features - DEV.log" 2>&1
  • Start in: C:\NotBackedUp\Builds\Fabrikam\Portal\_latest\Portal\DeploymentFiles\Scripts

Assuming this scheduled task completes successfully, each morning we have a freshly rebuilt Development environment with the latest build of our solution.

If the scheduled task fails, we can examine the log files to determine what went wrong.

Note that there are a number of enhancements in Team Foundation Server 2010 related to the build and deployment process. The process I've shown here is based on TFS 2008 (although it dates back to the old days of Visual SourceSafe and NAnt).


No comments posted yet.

Add Comment

Optional, but recommended (especially if you have a Gravatar). Note that your email address will not appear with your comment.
If URL is specified, it will be included as a link with your name.

To prevent spam from being submitted, please select the following fruit: Apple

Please add 4 and 3 and type the answer here: