Scheduling builds using Team Build

Today I've been having big fun trying to get an automatic build schedule together for the project I'm working on at the moment.

Yes, that's right. Trying. Nearly there, and there are several things I've learnt along the way about Team Build. Here are the important ones (in no particular order):

1) There's no inbuilt scheduler.
No real biggie, but before you spend half the morning looking for it, know that it's not there to be found. You'll just have to schedule it to run via Windows' task scheduler.

2) The command line tool TfsBuild.exe rules
See 1. Actually, I must say, the command line tool is really useful. It lives at:
<TeamBuildInstallDir>\Common7\IDE\TFSBuild.exe and is surprisingly good.
It can be called using:

TfsBuild.exe start <TeamFoundationServer> <ProjectName> <BuildType>

As you might have guessed, it'll go to your TFS Server, find the build type you've specified, download the configuration from source control (the current checked in version) and build based on that. Which I think is really neat.

It's not without its quirks, though. I spent ages feeding it different renditions of our server name (http://server, http://server:8080, etc...) and it kept on saying it couldn't find the server I was pointing it at. I found this post from someone who was having exactly the same problem, though, and the solution at the bottom worked for me. Go into the registry and find HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\TeamFoundation\Servers and add your server in there. Admittedly, I mimicked exactly what Joey Bradshaw did and put the friendly name of our server in as the key, and the full server name as the value. I don't know if the key is significant, but by this time I was getting hungry and wanted to go to lunch. Worked, though, which is the important thing.

3) Any kludges you've put together for getting your project to compile - better fix them properly
Yes, I know, this is pretty much the whole point of an automated build. But still. I came a cropper a couple of times with dll references.

We have a bunch of 3rd party and legacy dll's that we reference from our current project, which is fine. We keep them on a shared drive, the dll paths in the reference and the .refresh files in websites are pointing to that share, everything's happy. Until...

4) I'm buggered if I can work out what user account TfsBuild.exe runs under.
I kept on getting reports that the drive out shared dll's live on didn't exist. And fair enough, the standard shared drive mapping that all the developers use wasn't there. No biggie. Just log in under the account the Team Build service runs under, map the drive, and Bob's your uncle, yeah? No. Kept on getting the same errors reported that the drive didn't exist.

So I changed all the references in the source code to full network paths. Sorted, eh? No. Changed the permissions on the network share to allow the Team Build Service account read access, and it all worked fine. Go figure. It wouldn't pick up the drive I mapped under its account, but it's definitely the account that goes fishing about on the network to find those pesky dll's.

Oh well. It's done now.

So (at last!) I've got a successful build going on. Yeah?

Almost...

5) Your project may well compile, but your Unit Tests might not...
Once I got my main project to build, I shifted my Test project from the old server to the new. Yeah yeah, I should have done all that when I first moved the rest of the project, but hey, this is me. It was Friday and I just wanted to get everything working and go home.

So I moved my Unit tests over, changed all the external references (as I had discovered already. Built fine. Go to run it? Nope. Unit Tests don't run at all. Compile fine, but won't run. You'll need to give the dll's in the shared folder elevated elevated privileges to get them to run (elevated from the normal Intranet code group, anyway).

6) There's nothing better on this earth than that little green tick!
No matter what people tell you. When you see that green tick, there's nothing better!

7) Once it all works, it Team Build really does rule!
The reports Team Build produces are so cool. They're so comprehensive, and the integration with the rest of Team Foundation Server is fantastic. Once your project builds, it'll go back and See what changes have been checked in since the last successful build. It'll find all the work items associated with those changesets, indicate on them all that those changes have made it into a build, and give you some friendly statistics and scary numbers to tell your boss.

It'll even create a new work item if it fails that links to the failed build report and tells you to fix it!

All in all. It's been a bit of work today, and it's not quite over yet. But we're now running automated nightly builds and loving every second of it!

Just wanted to share.