We recently wanted to add a manual verification to our TFS builds. We didn’t want someone accidentally clicking the build to production when they meant to build to development. They are right next to one another and look very similar.

I didn’t want to spend a lot of time on it, so I came up with this. It’ll work for now and ensure we manually interact with the queue build dialog.

<Target Name="BeforeEndToEndIteration" Condition="'$(C***)' != 'suck'" >
    <Error Text=
"You did not state your feelings for the C***. Please state this by submitting
 the parameter /p:C***='suck' in the queue build dialog."/>
</Target>

The parameter name realy isn’t “C***”, but I didn’t want to offend any followers of the team with the longest championship drought of any professional sports team. Actually, I bet it is safe to extend that to individual performers too.

We’re using TFS 2008 and Team Build to compile and build a website mixed with ASP.Net and classic ASP. It works fine, but the only problem is the site is huge. It’s over over 2500 files and over 400 megs. That’s HUGE! We could XCopy that to our server, but pushing 400 megs every time feels like a little bit of overkill, especially when the majority of the changes are copy updates. We could also use a content management system for this, but we thought we would give try it with TFS.

First, it took forever to pull 400 megs out of source control every time we did a build. We can fix that.

<PropertyGroup>
    <IncrementalGet>true</IncrementalGet>
<PropertyGroup>

Done. Now the build will only pull down the files that changed. It’ll leave the files from previous build laying around on the server, but that’s OK.

Next, it takes forever to copy the 400 megs to the drop folder. We don’t even need to do it in the first place since we are going to xcopy the _PublishedWebsites contents elsewhere when we’re done. We can fix this problem with ease too.

<PropertyGroup>
    <SkipDropBuild>true</SkipDropBuild>
<PropertyGroup>

Now we won’t copy the build to the drop server.

So finally the XCopy. That was a little more tricky. We need to figure out only the files that change and transfer them, via FTP in out case. Luckily, Beyond Compare not only has a scripting interface that will let us work it into the build script, it also has the example script of how to do exactly what we want to do in the documentation. Win for us!

We can just tweak it a bit and we’re off to the races. Let’s make a script file called deploy.to.server.script and put it in the same folder as the TFSBuild.proj.

# %1 is source of the build to copy to the new server
# %2 is the outdir where the log should be written

#log the script actions
log verbose "%2\deployment.log.txt"

#set the comparison criteria
criteria timestamp size

#load source and target
# you could also use a UNC share
load "%1" "ftp://user:password@oursite.com"

# Move everything
filter "*.*"

#Sync the local files to the web site, creating empty folders
sync create-empty mirror:lt->rt

Next, invoke it in the build script.

<Exec
 Command="&quot;c:\Program Files\Beyond Compare 3\bcompare.exe"
 &quot;@$(MSBuildProjectDirectory)\deploy.to.server.script&quot;
&quot;$(SolutionRoot)\MyWebsite" &quot;$(OutDir)&quot;  \silent \closescript" >

We’re done. It’ll only copy the stuff we’ve changed and we’ve taken our build time from 25 minutes down to less than one.

Update: If you want to keep an eye on what you’re moving, add the following steps in the Beyond Compare script.

#load source and target
# you could also use a UNC share
load "%1" "ftp://user:password@oursite.com"

expand all
folder-report &
    layout:side-by-side &
    options:display-mismatches &
    title:"Deployment Report" &
    output-to:"%2\deployment.summary.html" &
    output-options:html-color

1/29/2009 11:40:42 AM  Fatal Scripting Error: Unable to load base folder
1/29/2009 11:40:42 AM  Script completed in 0.01 seconds

One more update: Here is a copy of the edit to the TFSBuild.proj file. This gets added at the end of the file before the closing <Project> tag.

 	<PropertyGroup>
		<IncrementalGet>true</IncrementalGet>
	</PropertyGroup>

	<!-- Since we are doing the source side by side we deploy before
		copying to the the builds folder. We might consider changing this
		to AfterDropBuild and copy from there if we are doing the precompiled
		websites -->
	<Target Name="BeforeDropBuild">
		<CallTarget Targets="Deploy"/>
	</Target>

	<Target Name="Deploy">
		<!-- Create a Custom Build Step -->
		<BuildStep
			TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
			BuildUri="$(BuildUri)"
			Name="BeyondCompareDeployStep"
			Message="Deploying to webserver">
			<Output
				TaskParameter="Id"
				PropertyName="BeyondCompareDeployStepID" />
		</BuildStep>

		<!-- We are deploying the source side by side with the pages instead of
			doing the precompiled website-->
		<Exec Command="&quot;c:\Program Files\Beyond Compare 3\bcompare.exe&quot; &quot;@$(MSBuildProjectDirectory)\deploy.to.server.script" &quot;$(SolutionRoot)\source&quot;  &quot;\\myWebserver\path\to\mysite&quot;  &quot;$(DropLocation)\$(BuildNumber)&quot;  \silent \closescript" >
			<Output
				TaskParameter="ExitCode"
				PropertyName="BeyondCompareExitCode" />
		</Exec>

		<!-- These tests don't work as BeyondCompare will ALWAYS exit with code 0 from script -->
		<BuildStep
			Condition="'$(BeyondCompareExitCode)' == '0'"
			TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
			BuildUri="$(BuildUri)"
			Id="$(BeyondCompareDeployStepID)"
			Status="Succeeded"/>
		<BuildStep
			Condition="'$(BeyondCompareExitCode)' != '0'"
			TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
			BuildUri="$(BuildUri)"
			Id="$(BeyondCompareDeployStepID)"
			Status="Failed"/>
		<Error
			Condition="'$(BeyondCompareExitCode)'!='0'"
			Text="Deployment Failed" />
	</Target>

The olny other file is the deploy.to.server.script file. This file sits aside the TFSBuild.proj file and looks like this.

# %1 is the solution root of the build
# %2 is the target location (ftp or share) to deploy
# %3 is the outdir where the log should be written

#log the script
log verbose "%3\deployment.log.txt"

#set the comparison criteria
criteria timestamp size

#load source and target
load "%1"  "%2"

expand all
folder-report &
    layout:side-by-side &
    options:display-mismatches &
    title:"Deployment Report" &
    output-to:"%3\deployment.summary.html" &
    output-options:html-color

filter "*.*"

# we want to override all the read-only files that exist
option confirm:yes-to-all

#Sync the local files to the web site, creating empty folders
sync create-empty mirror:lt->rt

After the disappointing ending to my previous post, I now have much success to report. Once we had the correct path to the MSTest.exe on the build server, I was able to publish the results of my NUnit tests. There are a few things to note.

1. You still need MSTest.exe on the build server. I guess that is OK since we, at our organization, want to allow for the ability to run MSTests as well. I’m not 100% sure that happens on the build server or the TFS server.
2. As of now, if the NUnit tests fail, it will not run the MSTest. This is because we are executing the NUnit tests in the AfterCompile target as suggested in the NUnit for Team Build example. I’m not really sure why you would do both in the same solution, but if you do, you won’t see failures from both. Only one at a time. I’m looking into getting both to run, but that isn’t going to be much of a priority since we won’t need to run both in the same solution.

I am really excited that we have this running with such little effort. Thanks has to go to the NUnit for Team Build guys.

One to step two when time allows.

While working in an MSBuild file I notice ReSharper will help you out with using new tasks. If you use one it doesn’t know, it’ll offer to add its UsingTask statement to reference it.

It’ll throw this in at the top of the document.

<UsingTask TaskName="Fooberry" AssemblyName=""/>>