I've been setting up our official project for Team System today and last week.  I started by creating a new Portfolio project and configuring permissions.  Then I used the Application Designer to create the skeleton Win Forms app, Web Site, Web Service and Windows Service.  I then added a bunch of empty class libraries for security, data layers, a rules engine and unit tests.  Plus a database project for db creation scripts and ad hoc queries.  All up, it's 14 projects currently, but we will add more for each set of rules for the rules engine (these will be dynamically loaded).

Once this was all done and compiled (it doesn't do anything yet) I checked it in to Team System Source Control (there's got to be a shorter name for it than that!).  I had to make sure it was successfully compiled first as I added a Check in Policy that requires a clean build before check in.

Next I tried to create a Team Build.  The Wizard to do this is very simple to use.  From Team Explorer, right click the Team Builds in the required project and select New Build Type.  You should see a dialog that looks like this:

In my case, I had an error telling me that I did not have any valid workspaces.  A workspace is like a working folder in Visual Source Safe - expect you can have multiple workspaces defined.  This was due to a stuff up on my part when I installed the Team Suite.  To fix this I created a new Workspace using the Source Control menu in VS, and assigned my new project to it.

After clicking Next you will see something like this:

You may have multiple solutions in the current portfolio so this page lets you select which ones to include and from which workspace.  Next you will see this:

Here you can specify which configuration(s) to build.  Next comes the build location page where you identity the server that is doing the build and the paths.

And finally you need to configure the build options:

Now for the tricks. Once you've created the build using the wizard you can only edit it as an XML file.  There is no nice gui editor.  So, whether you like it or not, your going to have to learn something about MSBuild. 

Additionally, you need to have permissions to edit builds as they are stored in the Source Control in a different path.  I had to give myself "Administer a build" permissions even though I am already a global namespace administrator.  This took a while to flow through the system too, I suspect because of ADAM (thankfully, I believe the ADAM requirement is disappearing from future releases).

When you select to Run Test, you need to specify a metadata file.  This file is created/updated via the Test Manager where you create test lists.  So, you need to create some tests first.  When you create a Test project, you should get an empty unit tests.  If you select "All Loaded Tests" the test project will contain tags like this:

When you have your own list of tests, you will need to modify this manually by adding /testlist:<list name> to the TestingArgs tag, e.g:

    <TestingArgs>/testmetadata:$(SolutionRoot)\Airways.SUMS\Airways.SUMS.vsmdi /testlist:All My Tests</TestingArgs>

I had one more problem.  When I created the empty projects, I specified that I wanted them all signed and I generated a temporary key file (.pfx).  This would not build so I had to remove all these for now.  I can easily add these in again when we get closer to release.

After a few more false starts, I managed to get a build to work.  Each time the build executes, you get a nice build result you can view that looks like this:

In this instance you can see that the build failed, there are 3 projects with errors and there is a single changeset included in this build.

To find the location of the errors, you currently have trawl through the build log - which can be rather long - but searching for ERROR usually finds what your looking for.  It would be much nicer if you could double click the project in the Compilation errors and warnings.  Not sure if this is planned or not but I've asked.

I also got a Work Item (86) for the failed build:

When I figured out what was wrong and fixed it, I associated this work item with the next check in and you can see that my comment was added to the work item and it was set to Resolved.  Very cool!

Summary

Theres a few more things I need to figure out, like scheduling an overnight build or having the build execute automatically after a check in (for Continuous Integration).  Also, the build results are appearing on the Project Portal page (but I have another project where they do appear).  So, there's still a few small bugs I guess and lots more to learn, but trying to do this sort of thing without Team System has in the past been very time consuming and not nearly as integrated.

During the next few weeks we'll be writing some code to actually have this application do something useful, then we'll hopefully see some real results.

Footnote:  To install Team Build, run the setup in the BB folder of the TFS Server disk.  BB stands for BigBuild.