Implementing Team Build, part 2

(A continuation from Implementing Team Build, part 1)

Setting up

So, where to begin? Well, for one thing it's good to know how Team Build works and what you can do with - and not. MSDN is as usual a great source of information (although there's an awful lot of it, you might miss some important bits in all the "debris"). Ewald Hoffman's posts on how to Customize Team Build 2010 was also a great source of information that we followed almost word-for-word. My colleague and I also had the 'luxury' of attending a course in administering Team Build that was useful, although somewhat railroaded (as courses tend to be).

Use third-party or make your own activities?

Well, both it turned out. We set out to use Community TFS Build Extensions as much as possible, but in those cases these didn't live up to our specific requirements, we made our own. In some cases, we extended activities from TFS Extensions (we're going to submit these changes back once they're thoroughly tested). 

Project set-up

As we were certain that we were going to need custom activities, we followed mr. Hoffman's guidance on how to set up a project for this. This is crucial, since when you've started adding your custom activities to a build process, that process cannot be read without first opening the project/solution.

One caveat is that if you are going to use more than one process template for your builds, you will need to edit each of them in an XML editor in order to make the project compile. Visual Studio for some reason want's each process template to use unique tags to the common activities, so we had to difference each process template by exchanging the top line

<Activity mc:Ignorable="sads sap" x:Class="TfsBuild.Process" ..>

with

<Activity mc:Ignorable="sads sap" x:Class="TfsBuild2.Process" ...>

for each extra process template you have in the solution.

Assembly locations

A build controller can have one and only one source-controlled folder where custom/external assemblies can be found. This might seem limited, but that's how it is. We selected to have a folder outside of the project where we also stored the assemblies for TFS Community Build Extensions. This meant that deploying our own assemblies is somewhat cumbersome (checkout, build, manual copy, checkin), but it works.

Remote debugging

Being able to debug custom-made activities would have been awesome, and we followed Hoffman's post on how to set this up. But we never got it working, no matter how much we tried; in the end we gave up and did it the hard way, i.e. make changes, code review, build, checkin new assemblies and test run. This meant that using Team Build in production got somewhat delayed since we wanted just about everything to work before starting to use it for "real" builds.