Introduction

Overview

At the time of writing this, Visual Studio Team System has been out for several months. In my previous book, Professional Visual Studio 2005 Team System (also published by WROX-ISBN: 0-7645-8436-7), the focus was specifically on the features of the product. This book takes a slightly different approach- rather than look at features, we will look at common tasks and scenarios around the entire software development lifecycle (SDLC).

Important

Team Foundation Server has an interesting history of codenames. The original codename for Visual Studio 2005 Team System is Burton (named after a ski equipment company). The majority of the features in Team Foundation Server include codenames derived from landmarks in North Carolina. (Microsoft has a development office based in Raleigh, NC.) For example, the Team Foundation Server SDK is codenamed Bodie (after the Bodie Island Lighthouse near Nags Head). Currituck is the codename for the Team Foundation Work Item Tracking feature (named after the Currituck Beach Lighthouse). The Cape Hatteras Lighthouse provided the namesake for Team Foundation Version Control. Finally, the Ocracoke Island Light provided the codename for Web and load testing. Rob Caron has provided a series of blog posts describing these landmarks in detail. You can read them at the following address: http://blogs.msdn.com/robcaron. The "Foundation" part of Team Foundation Server describes the foundation of support for team software development. The elements include source control, workflow, build services, and reporting.

In case you've never heard of Team System, it is a new product developed by Microsoft to support not only developers but also other members of development teams such as architects, database professionals, testers, and product managers. Team System is much more than Visual Studio-it includes a worldclass version control system, build server, a workflow and bug management system, reporting, and much more.

As companies start to work with Team System, they will inevitably encounter challenges such as implementing IT governance (Sarbanes-Oxley comes to mind), working within mixed environments (Java and .NET, for example), and setting up the product for large distributed environments. This book addresses these real-world challenges and much more. The contents are based on the practical experience of two Microsoft Team System Most Valuable Professionals (MVPs) and a host of sources within the product team.

Unlike other Team System books that may focus solely on developers, this book targets the project manager, administrators, and IT professionals. If you happen to be in one of these roles (or you are a consultant or systems integrator), you'll find a lot of great pragmatic information and step-by-step guidance within the pages of this book. We tell you how to handle a variety of tasks including setting up and administering Team System. This includes planning, project creation, and even properly completing a software project at the end of a development cycle.

The book provides a lot of depth on a variety of features in Team System; however it does not cover the whole of the product. For example, there is very little information provided about the Visual Studio 2005 Team Edition for Software Architects or Domain Specific Language (DSL) tools. If you would like a full overview of Team System, we would highly recommend you pick up Professional Visual Studio 2005 Team System published by WROX Press. All efforts have been made to diminish the overlap between books and in fact, you'll find them to be quite complimentary.

When deploying Team System, it's a natural tendency to be thinking about the development process. Thus you will probably be thinking about how your own teams are organized, continuous development, builds, refactoring, and so forth. However, it's important to look at a deployment on many levels (as shown in Figure IN-1):

Figure IN-1

When you deploy and use Team System, there are multiple lifecycles you have to take into consideration:

• Operational lifecycle- Before even starting a single team project, you have to install and support Team Foundation Server, and the other components of Team System. Most users start team projects as soon as they install the product (as shown in Figure IN-1). However, the tasks related to the ongoing maintenance of the product overlap with many team projects. The Microsoft Operations Framework (MOF) based on the IT Infrastructure Library (ITIL) provides great guidance on how to manage your environment, including Team System.

• Software development lifecycle- The software development lifecycle (SDLC) is what drives Team System. You can use a variety of methodologies to drive your development efforts including the Microsoft Solutions Framework. Each Team Project has its own lifecycle, and within a Team Project, you may have a series of smaller iterations or milestones.

• Data development lifecycle- In May 2006, Microsoft announced the Team Edition for Database Professionals, which allows database developers and administrators alike to manage database schemas in very much the same way a software developer manages code. You'll notice in the graphic above that the data development lifecycle (DDLC) mirrors the lifecycle of a team project. You would be hard pressed to find an application that doesn't use a data driven infrastructure. Therefore, it's logical that the continuous creation, development, and release of database schemas occurs at the same time as your application development process.

• Business continuity and resource management- What is not represented in the previous figure is the business infrastructure required to run a successful software development company. Microsoft has many enterprise planning and management solutions such as Microsoft Dynamics, Microsoft Project Server, Microsoft CRM, and many others to handle the business side of operations.

Important

When you start working with Team System, what you may not instantly realize is that it was fundamentally designed to implement and promote software engineering practices and process improvement. It also promotes transparency and friction free software development in the spirit of Agile development. A Team System deployment isn't just about installing a set of tools-it's an opportunity to revisit your practices; implement proper patterns and coding conventions; and set up the right scalable branching structures, adaptable builds, and predictable workflow.