Team Development With Visual Studio Team Foundation Server

Team Development with
Visual Studio Team
Foundation Server

1

Team Development with Visual
Studio Team Foundation
Server

patterns & practices

J.D. Meier
Jason Taylor
Alex Mackman
Prashant Bansode
Kevin Jones

Information in this document, including URL and other Internet Web site references, is
subject to change without notice. Unless otherwise noted, the examplecompanies,
organizations, products, domain names, e-mail addresses, logos, people, places, and
events depicted herein are fictitious, and no association with any real company,
organization, product, domain name, e-mail address, logo, person, place, or event is
intended or should be inferred. Complying with all applicable copyright laws is the
responsibility of the user. Without limiting the rightsunder copyright, no part of this
document may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical, photocopying,
recording, or otherwise), or for any purpose, without the express written permission of
Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other
intellectualproperty rights covering subject matter in this document. Except as expressly
provided in any written license agreement from Microsoft, the furnishing of this
document does not give you any license to these patents, trademarks, copyrights, or other
intellectual property.
© 2007 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows NT, Windows Server, ActiveDirectory,
MSDN, Visual Basic, Visual C++, Visual C#, Visual Studio, and Win32 are either
registered trademarks or trademarks of Microsoft Corporation in the United States and/or
other countries.
The names of actual companies and products mentioned herein may be the trademarks of
their respective owners.

Foreword By Jeff Beehler
Foreword
Before we released Microsoft® Visual Studio® 2005 TeamFoundation Server (TFS), we
first used it to develop TFS. For the final 18 months of the project, we used it extensively
to manage the development life cycle of our project, a practice commonly known as
“dogfooding.” Through this dogfooding, we learned a lot about the powerful system that
we were creating. We certainly found and fixed many quality issues so that the resulting
product was muchmore stable and performed better than we could have achieved
otherwise. But perhaps more importantly, we learned about ways to best use (and not use)
the tools we were creating. This experience, in conjunction with feedback from our
customers on their practices, forms the basis for this guide.
At first glance, one might expect this information to be included with or to replace the
productdocumentation. In fact, at one time, I held that belief as well. However, as I’ve
worked closely with J.D. Meier and the other authors of this guide, it’s become clear to
me that this split is both natural and important. I think the best way to describe it is to
compare the two guides to your car’s owner's manual and a driver's guide ― you need
both, but for different reasons. Traditionally, theproduct team has focused on product
documentation and left the guidance aspect to others. While we still depend on others to
help us out here, we're starting to invest more of our time and energy in the guidance
portion because we realize how important it is to the successful adoption of our product
and its role in increasing overall customer satisfaction.
Like a car, TFS is a powerful toolthat can take you and your team nearly anywhere you
want to go; this guide can help you get there. Every team approaches TFS somewhat
differently depending on its particular needs and history. For this reason, we’ve written
this guide in such a way as to allow you either to read it from cover to cover if you want
the full picture, or to dive into specific topics as your needs dictate....