Visual Studio Team Foundation is the server part of Visual Studio 2005 Team System (VSTS), and is built on the .NET platform. It is an extensible team collaboration server for managing project assets, progress, and health across the extended IT team. It drives an organization's policies, practices, and processes. It controls access to source files, enables users to create and manage work items, facilitates reporting, automates the process of building applications, and manages releases. It was designed from the beginning with open protocols and an extensible Web services architecture exposed through .NET client APIs. Team Foundation is tightly integrated into the Visual Studio 2005 IDE and supports numerous customizations from third parties and customers.
Every project begins with a process. Simply put, a process is the system that your organization uses to get the project done. Team Foundation enables projects to begin and move forward effectively by helping you manage the process for your team. No single process can work efficiently for all projects in your organization. You often need to be able to create new processes or customize existing ones and ensure that the resulting processes remain tightly integrated into your life cycle tools and guidance. Visual Studio 2005 Team System provides that customizable process guidance and integration using Microsoft Solutions Framework.
The Microsoft Solutions Framework (MSF) provides guidance regarding people and processes that enable you to successfully deliver technology solutions to your customers. MSF is a disciplined approach to technology projects based on proven practices related to how Microsoft delivers projects in-house.
Microsoft Solutions Framework (MSF) version 4.0 is the next evolution of the Microsoft Solutions Framework. MSF 4.0 exposes a meta-model (or framework) on which processes are built. Visual Studio Team System integrates this meta-model with a template mechanism to produce process templates. Each template defines a set of instructions for setting up a new project. This includes the project's initial tasks, project roles and permissions, document templates, and reports. Each process template can be used as is or customized to fit the needs of one or more projects. After a project has begun, you can further customize many of the process template settings.
Because every organization works differently, Visual Studio 2005 Team System defines two process templates. One is called MSF for Agile Software Development. It provides an adaptive, lightweight template for projects with short life cycles and results-oriented teams. The other process template lends itself to a more formal approach and is called MSF for CMMI Process Improvement. It targets projects with longer life cycles requiring a more thorough record of decisions made. Both templates follow an Incremental and Iterative Development (IID) approach to software development, called the Agile approach.
Both MSF 4.0 templates are available out-of-the-box through Team Foundation Server. As such, they are fully integrated into the Visual Studio 2005 Team System IDE or Team Explorer and provide customizable scenario-driven, context-based software development processes for enabling customers to build new or improve .NET or other platform and architectural-type applications.
Templates are not limited to the MSF approach. Visual Studio Team System process templates can be created to guide the development of projects based on the Rational Unified Process (RUP), Agile Unified Process (AUP), Extreme Programmer (XP), and MSF Waterfall. If you want more detailed information about MSF and process templates, we highly recommend you read Chapters 21 and 22.
In addition to enabling the right level of process for any given project, Team System also provides guidance that helps you move forward at each step along the way. No longer do you need to hunt around for the right documentation to help solve a problem at hand. Team System not only provides the right guidance at the right time, it exposes the right tools to propel you forward, provides guidance that is well integrated into Visual Studio Team System, is highly customizable, and enjoys updates delivered via MSDN.
An example of integrated project management guidance is the Team System-enabled Microsoft Project. MSF guidance is provided for a number of Microsoft Project–related tasks associated with your project, including defining the project and its work items, organizing the work item tasks into phases, adding documents to the project, and so much more.
After planning your tasks in MS Project, you can review resource guidance on how to build your project's team and assign tasks. Once the project is defined and resources are assigned, Team System provides further guidance on managing the project once it has begun. This includes checking the progress of the project and publishing project information to the web.
Reporting is another area of guidance, including how to report the status of your project and publish these reports to the web.
Armed with an overview of the process templates and guidelines, we can now turn to an overview of the tools of Team Foundation Server that are central to making team processes a reality.
Team Foundation provides a number of new tools (some of which were previously only internal to Microsoft) to facilitate team collaboration, communication, and productivity. At a high level, Team Foundation consists of the following:
Version Control: A new enterprise-class three-tier version control system with powerful merging and branching capabilities. It is designed to effectively manage not only source code, but project files, documents, reports, and templates.
Work Item Tracking (WIT): A customized version of an internal defect-tracking tool used by the majority of internal Microsoft product groups. It has been expanded beyond defects to support tracking many units of work that need to be performed throughout a project.
Team Portal: Built on Windows Sharepoint Services 2.0, this is used to facilitate team communication. From this site, it is possible to run reports, review work items and docs, and perform daily builds.
Team Foundation Build: Out-of-the-box support for daily build management.
Team Reporting: Provides a systemwide data view of one or more projects residing on TFS.Built on SQL Server Reporting Services.
Project Management: Integration with Microsoft Office Project 2003 and Microsoft using Visual Studio Tools for Office (VSTO) technology.
Integration Services: A set of Web service and object models that allow outside tools to integrate into the Team System environment as first-class citizens. The provide customization and extensibility support for each tool offered in Team System.
Team Explorer: A thin shell of Visual Studio that supports many of the features of Team Foundation Server. It does not contain any of the development or test tools normally associated with Visual Studio (e.g., languages, compilers, debuggers).
Team Foundation version control is an industrial-strength change management tool for managing assets and work items. It includes all the facilities for changesets, rich branching, merging, and "diffing" that you'd expect from an enterprise-scale source code control system, as well as innovations around parallel development, atomic check-ins, and remote development. Team Foundation version control is tightly integrated into the development environment, so the developer never needs to leave the VS IDE.
Team Foundation version control is not simply a standalone system for managing source code. It's tightly integrated with Team Foundation's policies, e-mail notification, build automation, data warehouse, and work item tracking system. For detailed information about Team Foundation version control, please refer to Chapter 20.
At the heart of Team Foundation version control is the changeset. A changeset is a logical container used by Team Foundation Server to store everything related to a single check-in. This container may include files (source code and nonsource code), meta-data associated with the file(s) such as data and time of check-in and the owner's name, and any check-in notes or comments. A changeset may also include links to other artifacts (documents, work items, and so on).
When a set of pending changes are checked in, Team Foundation creates a new changeset in the source repository and assigns it a number that is unique on a given server and always increases by one from one change to the next. In this way, a changeset represents the state or version of the repository at a given point in the past. It's often important to be able to go back and identify these past states, such as identifying a past build. Identification is done by assigning a label to the state of the repository after a build is produced. Using this label, others (e.g., a partner team) can identify, pick up, and use the published build.
By the way, check-in in Team Foundation is atomic. That is, the operation is all or nothing, so either all the files are checked in or none of them are. Atomic check-in resolves the problem of corrupted repositories. If a network is lost halfway through a 100-file check-in, then all files will be uncommitted and restored to their original state on the workspace and server repository (more about this later). At the time of this writing, being able to back out of a changeset is not yet possible.
This changeset functionality enables revisions to one or more related files, comments, work items, policy, and e-mail to work as a single process. Integrated check-in enables a work item to be associated with a pending check-in by simply adding a link between the two using the UI. When the changeset is checked in, the user has the option of specifying a "check-in action." The default action is to set the state of the bug to Resolved.
When the bug is resolved, revisions of these files are checked in and a new changeset artifact is created with a unique identifier in the source control repository to contain the data and related metadata. Upon check-in, this work item is updated to refer back to the new changeset, maintaining the linkage between the work item and changeset. This links the corrected code to the bug for anyone to see. This type of linkage is not the only scenario, however. Code can be linked to work item types to map other forms of interaction.
A workspace is your client-side copy of the folders and files on the Team Foundation version control server. Any changes (e.g., delete, modify, move, rename) to these folders and files are reflected in your workspace and marked as pending changes. You can edit, build, and test your code without worrying how your activities might affect your teammates or checked-in source code. Once these pending changes are checked in, they will be atomically committed and persisted to the server version control repository. Any subsequent changes to your workspace will not be reflected in the server until the next successful check-in.
Team Foundation version control enables a team with an existing code base to branch all or part of that code base to facilitate parallel development. After changes to the various branches become stable, they can be integrated back into the original code line. A number of different scenarios are applicable to branching and merging. One is release branching, whereby, for example, branching and merging enables a maintenance team to work on a code line for fixing bugs and releasing patches separately from the released product's source code.
Branching in Team Foundation version control is similar to Visual SourceSafe. Both handle branching analogously to a file system copy operation. When a file is branched, it is as if a new file were created with a unique identity. In fact, the Foundation Source Code branching UI in Visual Studio looks very similar to a file copy operation within Windows Explorer. However, there is a notable difference. Unlike file system copies, branching maintains relationships between the files of the original and the new branch. This enables all changes to be easily tracked and "merged" between the two.
Team Foundation version control manages branches holistically. Any type of change within the branch (files added, renamed, deleted, or edited) will be handled when the changes are merged. As discussed earlier, Team Foundation version control uses changesets to manage changes to a set of files that are checked in at the same time. These changesets make it possible for the system to automatically identify the set of files that need to be merged for a given change.
Branching in Team Foundation version control is a pending operation. A branch is not actually created until the files are committed to the repository. This affords the user the opportunity to synchronize the new branch to a local workspace. It also enables you to modify, rename, and delete files and folders before the branch is committed to the repository.
Merging gives users an extremely flexible and powerful tool for managing the contents of branches. Merges can be made into a single file or into a tree of related files. Merges can also migrate the entire change history of the specified source files, or an individual changeset or revision that may contain a specific fix or feature that should be migrated without moving other changes from the source in the process.
Source control maintains a history of everything that has been merged. This enables you to easily see whether a change exists in a given branch. You can also easily see a generated list of changes in one branch (changesets) that have not been merged and are candidates for a future merge operation. You can "cherry-pick" specific changes, such as a bug fix, and merge it without also pulling over other changes that were made to the same files in earlier revisions. Using changesets provides an atomic (transactional) package, which makes change management a great deal easier.
What should a developer do when a manager tells her to drop everything and immediately fix a high- priority bug? She probably can't store her unfinished work on her workstation, as that is likely against company policy. Nor can she check in her changes to the server, as it will likely break the build. With Team Foundation version control the developer can now shelve it.
Team Foundation version control provides an archiving command called shelve that enables a source control user to store pending changesets on the server without committing it to the Source store. These changesets are called shelvesets when used in the context of shelving. Users can use shelving to simply back up the current changes to make it easy to get back to a known state or to move their changes out of their workspaces. Because the changes are saved on the server, they are transferable to other users. This enables sharing changes as well, thereby enabling changes to be reviewed and tested on another machine by other users prior to committing them. The following code is a command-line example of shelving:
> tf shelve HelloWorldBuddyReview;Erik c:\myprojects\*.cs /recursive
This example creates a new shelveset on Team Foundation Server called HelloWorldBuddyReview. It assigns ownership to the user named Erik and returns all C# source files under the c:\myprojects workspace folder (and subfolders) that are pending.
Team Foundation provides version control proxy support for developers working from remote offices on inadequate network bandwidths and suffering from slow file downloads from the Team Foundation Server. The proxy works by locally caching copies of source control files. This significantly improves the time it takes to download files to a user's workspace, which is a bandwidth-intensive operation, as it uses the LAN instead of the WAN. Proxy support will not change how file uploads and meta-data are exchanged with the Team Foundation Server. Remote office users will still need to communicate across the WAN for check-ins and meta-data exchanges, but this represents a fraction of the data transferred in working with source control. This proxy-supported solution is much less expensive to administer and maintain than source control products offering multi-master solutions.
The most noticeable proxy performance is obtained when the middle tier has a limited bandwidth connection to the client, and both proxy and client are located on a network not challenged by these bandwidth limitations.
Team Foundation version control proxies can make a significant difference in performance over nonproxied cases. Over a single-digit Mb connection, proxies can provide considerable improvement, up to 20 to 30 times faster.
Visual Studio Team Foundation enables team project administrators to enforce compliance with organizational rules during the check-in process. This is accomplished through a check-in policy. A policy is a guideline that governs what conditions must be satisfied before a Software Configuration Management (SCM) operation is performed. A check-in policy is a team-specific source control integration guideline. They are only set at the team-project level. It is used to validate that a developer's changes comply with organizational requirements before a set of pending changes are checked into the repository. When a developer attempts to check in pending changes that are in breach of team policy, a policy warning is raised. Because a policy is considered a reminder, and not a directive, the developer can elect to ignore policy warnings. However, they will be prompted to explain why they have elected to override the check-in policy.
The following check-in policies ship with Team Foundation:
Validating that work items are associated with changes
Unit tests pass successfully
Static analysis has run cleanly on source code
You can write custom check-in policies fairly easily using some of the same interfaces exposed for the check- in policies that ship in the box. You can install a custom source control check-in policy by adding a new string value with the policy's name and the path to the DLL implementing these interfaces at the registry:
There you will see the policies that are installed at setup. Details on how to create custom check-in policies are provided in the Team Foundation Extensibility Kit.
It is interesting to note there is no check-out policy. To keep track of status, the developer would need to regularly update the status of the "in-progress" work items. Microsoft Project work item integration could be used if the work items have been scheduled in Project.
Team System provides a tool for migrating source code from Visual SourceSafe to Team Foundation using the VSS converter tool (VSSConverter.exe). This tool enables teams to move from a source control tool targeted at professional software developers working in groups of less than five to a change management system that provides integrated version control, process management, and issue tracking for development teams of five to upwards of two thousand users working on a single instance of Team Foundation Server. You'll learn the precise steps of how to migrate your source code in the Team Foundation Version Control chapter. Over time, Team Foundation and/or third parties will provide migration tools from other version control tools.
Team Foundation's work item tracking capabilities enable a new level of software development life cycle tool integration. It provides the glue that binds the software development team's processes together and enables the team to accomplish the tasks necessary to successfully move a project from envisioning to deployment. Work item tracking (WIT), like source code control, plays a vital part role in successful software teams.
At the center of work item tracking is (of course) work items. A work item can be a bug, a task, a requirement, a risk, a schedule, a Design Change Request (DCR), or essentially any project artifact type any member of the team needs to track. Each work item maintains meta-data such as its owner, area, or the iteration of the project to which it is assigned. Work items may also be linked with other project artifacts. Each work item defines the states it can transition through. For a bug, these states may include (but are not limited to) opening, verifying, triaging, reassigning, and closing a bug. Because every project has its own needs and requirements, these work items can be customized, or new work item types can be created for the project using the Team Foundation Extensibility Kit.
Integration is a driving force behind Team System. This is integration with other tools as well as deep integration among the Team System tools and components. It is the work item tracking system that ties into all aspects of the software development life cycle. Therefore, it is critical that work item tracking be tightly integrated with other enterprise tooling efforts. WIT provides the infrastructure, APIs, and object model that enable testing integrations and project management integrations.
Many tool integrations are brittle or provide a poor user experience because they have no common services for actions such as authorization, linking, eventing, and reporting. WIT uses Team Foundation integration services and a common reporting infrastructure (Warehouse) to avoid these tool integration problems, delivering one of the most integrated software development life cycle tooling solutions on the market. Work item internals and customization are covered in more detail in Chapter 19.
The single place to go for high-level project information is the Team System Project site. The Project Portal, built on Windows Sharepoint Services (WSS 2.0), provides lightweight access to all members of the team who may not wish to gain project visibility through Visual Studio. Using the portal, team members can view reports, review specs, and see announcements, among many other things.
The project portal can also be viewed within Visual Studio 2005 Team System via the Documents Node in the Team Explorer. Chapter 19 has more information about navigating and administrating the Team Portal.
Another tightly integrated feature of Team Foundation is Team Foundation Build. Team Foundation Build provides a simple, reliable, and repeatable build process that does not require the help of a dedicated build engineer. It is used by build engineers, developer leads, or testers who are responsible for the public build. A wizard enables users to easily create initial build scripts (MSBuild) that can be activated with a single click.
There is no need to know MSBuild, nor is it necessary to edit MSBuild XML scripts to initiate a simple build. Team Foundation Build is integrated with a number of Team Foundation components to enable an end-to-end build workflow. It not only includes traditional compilation, but also automates the build steps, beginning with initiating a build from a server, synchronizing sources, documenting the build environment, building the application, analyzing generated binaries, executing tests, generating exceptions, calculating code coverage and churn, updating relevant work items, collecting and creating release notes, to finally producing and publishing a centralized build report. For more information about Team Foundation Build, please refer to Chapter 23.
Team Foundation Reporting uses SQL Server 2005 Reporting Services to provide the team with a systemwide and historical data view of project metrics stored in the Team Foundation Data Warehouse (discussed later in this chapter). These reports include "stoplight" (red, yellow, green) health reports that clearly show work progress, test effectiveness (code coverage), and requirements stability, and informational health reports that show bug rates, team productivity, test effectiveness over build, work progress over time, requirements stability over time, and code completion. These reports can be viewed from the Team Project Portal Site, either directly from your browser or from Team Explorer.
If a report is not available, you can generate a custom report using Microsoft Excel, Visual Studio, or SQL Reporting Services. Team Foundation Data Warehouse provides the SQL 2005/AS Cube structure to build these. Examples of custom reports may provide support for the following:
The history of a particular test (result)
The difference between the results of two load tests
Status, in terms of testing of a scenario or requirement
If you wish to explore further, please investigate the Business Intelligence Development Tool in SQL 2005. It enables you to diagram facts and dimensions, the things you expect to see in cubes, for your report.
Reporting in version one of Team System provides some benefits for those facing some form of regulatory compliance, such as Sorbanes Oxley (SOX). For many in IT, SOX compliance centers on change management, user access, and segregation of duties. Being able to track who checked what source code in for what set of work items is one example of how Team System will play a larger role in governance. Perhaps future versions of Team System will address this aspect more fully, especially in the area of deployment. Please refer to Chapter 19 for more information about Team Reporting.
Visual Studio Team System was designed with extensibility in mind. In fact, the features we've described so far are all built on an extensibility model that enables integration between Team System components and in-house or third-party-provided process frameworks, components, and services. In addition to the Team Foundation integration services, each of the tools in Visual Studio 2005 Team System may be extended through its own services or public APIs. The API allows you to control Eventing, Linking, Registration, Group Security, and the Common Structure Service.
Although load tests are integrated into Visual Studio Team Edition for Software Testers, Microsoft enables you to go beyond this capacity using the Team Edition Test Load Agent. The Team Edition Test Load Agent is composed of a test controller and one or more agents. An agent is used to run tests and generate simulated load, and the controller collects the test results. Together, they enable you to set up a group of computers that generate simulated load for testing. The test controller and agent can be installed together on one computer or separately on two computers. One test controller can coordinate the test runs executing on agents installed on any number of computers.
Note that the Test Load Controller and Agent must be purchased separately from Team Foundation Server. If you try load testing on your local machine, you'll find that you'll encounter a practical limit of about 100 users. The Load Test Controller and Agent will allow you to greatly exceed that number.