I no longer work at Microsoft, so please don't bother leaving a comment here or trying to contact me through my MSDN blog.
You can find my new blog at http://www.technologytoolbox.com/blog/jjameson. My new site also provides copies of all posts from my MSDN blog.
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.
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:
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:
<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. -->
Condition=" '$(IsDesktopBuild)' != 'true' ">
<Output TaskParameter="CompilationSuccess" PropertyName="BuildCompilationSuccess" />
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:
The second step in the scheduled task redeploys all of the custom SharePoint WSPs and features for the solution:
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).