Team Build

Apr 2, 2007 at 6:11 PM
First off I also want to say thank you for all of the really helpful resources you've provided so far. They truly are worth whatever time you're taking to put them together. That said, one area of Team System I feel is greatly underserved from a documentation and guidance standpoint is Team Build. Frankly, I find that to be the area in which I have the most difficulty. In particular, how to best deal with 3rd party assemblies, configuration files for Dev/Staging/Production environments, etc. Not sure how others feel, but personally I would greatly appreciate seeing more content in this area.

Thanks again!

Apr 19, 2007 at 10:44 PM
Thanks for your kind words. We are actively working on Team Build over the next few weeks and you will soon see content posted on this site. We'll cover areas such as:
- How to set up a scheduled build (eg. daily or weekly)
- How to set up a continuous integration build
- How to set up a build for projects with shared binaries or code (eg. 3rd party assembly)
- How to set up a build for a setup project.
- How to set up your test and development environments

If you have any more suggestions, please let us know!

May 9, 2007 at 6:25 PM
At our company, there is a great interest in using TFS build process for SOX-compliance. In essence, we need to log every change that is made to any of the Finance related applications and track when it was deployed to production, who approved the change, etc. I have seen some demos that shows how TFS integrates the Work Intake Request with VSS (e.g. developer must assign a ticket# when code is checked in). However, I am not sure if the same type of integration exists with TFS Build.

Some guidance on this would be helpful.

Sep 7, 2007 at 12:17 AM
Our build guidance is now available here:

And here:

Regarding the last question on SOX-compliance tracking. Yes you can associate a work item with every check-in. This will allow you to associate each change-set with a work item and each build with a set of work items that were implemented in that build. Each work item contains full history of field changes, etc. so you should have the tracking you need. You can even require that every check-in is associated with a work item using a check-in policy.