Visual Studio 2005 Team System: Extending the Suite

  • Article

 

Allen Clark
Microsoft Corporation

May 2004

Applies To:

   Microsoft Visual Studio® 2005 Team System

Summary: Visual Studio 2005 Team System is an extensible set of software development life cycle tools that helps teams reduce the complexity of building modern service-oriented software and facilitates better communication among members participating throughout the development process. These tools are integrated through a set of integration services and tool-specific APIs that are publicly available for integrating additional tools. (8 printed pages)

Note   This document was developed prior to the product's release to manufacturing, and as such, you may find inconsistencies with the details included here and those found in the shipping product. The information is based on the product at the time this document was created and should be used for planning purposes only. Information is subject to change at any time without prior notice. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property 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.

Contents

Introduction
Team Foundation
Tool-Specific Extensibility
Conclusion

Introduction

Visual Studio 2005 Team System includes the Visual Studio Team Foundation platform and a set of tools. The Team Foundation includes:

  • Work Item Tracking
  • Project Management
  • Source Code Management
  • Integration Services

The additional tools in Visual Studio 2005 Team System are:

  • Architecture and Design
  • Public Builds
  • Code Analysis and Testing

The Team Foundation integration services may be used to integrate tools into the Visual Studio 2005 Team System in the following ways:

  • Visual Studio Team Foundation provides a set of services and defines a set of enablement APIs that permit tools to integrate with one another without becoming tightly coupled. For example, Visual Studio Team Foundation provides common referencing, event generation and handling, and classification services.
  • Tools can plug in to several key user interfaces to participate as partners that are equal to the native or other third-party tools. For example, a tool can participate in the creation of a new project or administer security.
  • Tools can add their data to the reporting warehouse, and draw on that data in reports.

In addition to the integration services, each of the tools in Visual Studio 2005 Team System may be extended through its own APIs or services. The following table shows the ways that each of the different tools may be extended.

Tool Ways the tool may be extended
Project Management and Work Item Tracking Customize work item types and process guidance for your workflow, and automate work item tracking using the work item object model.
Architecture and Design Add remote services, hosting environments, and constraints to the designer to provide richer, more detailed designs.
Source Code Management Define new file types and check-in policies, and automate source control activities using the source control object model.
Public Builds Incorporate new types of build steps into the build process.
Code Analysis Add annotations and rules to find more defects during static analysis.
Testing Extend the testing tools with new test types and use those in unit testing, build validation testing, and load testing.

Team Foundation

Team Foundation provides the foundation for integration between Visual Studio 2005 Team System tools, and it provides work item tracking and source code management tools.

Tools, Artifacts, Services, and Servers

A Team Foundation enabled tool is an application that participates in the Team System by implementing a set of enablement APIs and plugging into the Team Foundation extensible user interface. In some cases, the tool will have server and client components. Tools with server components provide a web service that implements the server-side enablement APIs. On the client, tools are integrated into the Team System by plugging into common user interfaces.

The Team Foundation enablement APIs provide the information that a tool manages in the form of artifacts. Each artifact has an immutable identity, and represents a meaningful unit of information to the user. Team Foundation Server integration services and the server components of each of the tools are Web services that together make up a logical Team Foundation Server. A Team Foundation Server may be deployed on one hardware device, or it may be deployed across many to handle larger loads.

Tool Registration and Discovery

Each tool registers itself with the Team Foundation and describes the set of artifacts that the tool manages, the set of link types that the tool supports, and the set of events that the tool raises. A tool can also register properties for its own internal use.

Other tools can use the registry to determine whether a tool is installed in Team Foundation Server and to obtain access to that tool.

Artifacts and links are core concepts by which Visual Studio 2005 Team System provides a common view over all of the data and relationships across all the Team Foundation enabled tools. Artifacts, such as work items and change sets, are the data. Links are the associations between artifacts.

Each tool implements a Web service that includes APIs that return information about the artifacts and links that the tool manages.

Event Generation, Event Handling, and User Notification

Tools register events that they can raise. Other tools' server components can subscribe to those events and respond appropriately. Tools can raise the events synchronously or asynchronously. A tool generally chooses to raise events asynchronously, except when the tool needs to know the response. For example, if a tool provides a veto mechanism for event subscribers, the tool should declare the event that subscribers can veto as a synchronous event. The programming model is effectively the same for both synchronous and asynchronous events.

Other tools, a Web service for example, can subscribe to Team Foundation events and respond to the activities that those events represent.

Tools that raise events can also provide e-mail templates for delivering notifications based on those events to end users. If a user subscribes to a notification, the user receives e-mail based on the template and the event content each time the tool raises that event. The user can optionally request notifications that summarize events on a daily basis.

Any subscription, such as an event subscription for a server or a notification subscription for a user, can include a filter. The filter specifies that Team Foundation should process the event content so that the subscribed Web service or user gets information that targets what is needed. For example, a user might subscribe to a work item change event and filter the subscription so that the user receives notification when someone assigns a work item to the user.

Group Management and Authorization

Each tool uses its own security model and manages the permissions for the tool in a way that is appropriate for that tool. If each tool were to maintain its own set of user groups for permission assignment, the task of maintaining groups and permissions would be burdensome for a user. For this reason, Team Foundation centrally manages a store of user groups to be shared across tools. Users need only work with a single set of groups.

Windows users and Windows groups can participate in Team Foundation user groups.

A tool can also use the authorization service to manage permissions for the tool by registering the objects and actions that the tool needs to secure. After the tool registers these items, an administrator can grant and deny permissions for these items. The tool then calls the authorization service to determine whether a user has permission to perform a specific action.

Portfolio Projects

When a team decides to use Team Foundation enabled tools, the team uses those tools to manage data for the entire effort of building a releasable set of software. That effort roughly corresponds to a portfolio project. The portfolio project can contain requirements, features, and source code that can include many Visual Studio project files, schedules, bugs, tests, and so on.

Administrators define portfolio projects in Team Foundation, and each tool typically operates in the context of one portfolio project at any point in time.

When an administrator creates a new portfolio project, Team Foundation notifies the registered tools so that the tools can take the steps necessary to represent the new portfolio project.

Portfolio Explorer

Portfolio Explorer helps users navigate between portfolio projects and into tool-specific features. For example, a user can navigate into a portfolio project on which the user works and then into reports or work items. Team Foundation enabled tools generally display at least one launch point in Portfolio Explorer.

Reporting Warehouse

Team Foundation provides a reporting warehouse in which tools can post data that can be combined and examined for trends over time by using Online Analytical Processing (OLAP). Each tool contributes data to the warehouse by retrieving the data from the data store for the tool, transforming the data appropriately, and posting the data through the warehouse API. The entire process of retrieving data from all of the tools and reprocessing the OLAP cubes is managed by a single, simply managed service. The warehouse simplifies the creation of reports that combine data from multiple tools and summarize the data along shared dimensions.

Tool Configuration

Each tool has its own set of permissions and other configuration settings. Team Foundation provides a common UI in which the tools can present their settings so that administrators can go to a single place to administer all of the Team Foundation enabled tools.

Project Management and Work Item Tracking

The Project Management and Work Item Tracking tool is used to plan and track a project's progress using work items. Several types of work items are available:

  • Requirement
  • Features
  • Scenario
  • Tasks
  • Bugs

Each type of work item has a set of fields and valid state transitions. The set of work item type definitions are bundled in a methodology template. When a portfolio project is created, the user selects his methodology, and the appropriate work item types are created. Two Microsoft Solutions Framework (MSF) methodology templates are delivered with Team Foundation—Microsoft Solutions Framework Agile and Microsoft Solutions Framework Complete.

Work item tracking can be customized and extended by:

  • Adding fields to a type of work item.
  • Changing the valid states and state transitions for a type of work item.
  • Adding new types of work items.
  • Customizing the Web portal template.
  • Customizing the process guidance.
  • Altering the set of process-related tasks that are included with each new portfolio project.

These changes can be bundled into a custom methodology so that they are applied to all portfolio projects created with that methodology.

The set of fields and state transitions are customizable for each portfolio project to support a work process or methodology. For example, a team may need to categorize bugs based on who identified the bug – a customer, the test team, the development team, or someone else involved with the project. To support this, the administrator adds a new field named "Source" to the bug work item and defines that field as a list that can have a value from the list:

  • Customer
  • Test
  • Development
  • Other Internal

Bugs in the portfolio project where this was defined now have this new field to track the bug source.

Suppose that tracking this information proved to be useful, and the management team wants all new projects to track bug sources. In this case, the administrator can add the new field definition to the definition of the bug work item type in the methodology template that drives portfolio project creation. Any new projects created with the modified methodology will include the Source field in the bug work item.

A team may decide to introduce its own methodology. For example, a company may have defined its own variation of the MSF Complete methodology. In this case, it can create a new methodology template that includes some or all of the MSF Complete work item types, with modifications, and perhaps some new work item types. When a portfolio project is created with the custom methodology template, it will have the work item types that support the company's specific methodology.

In addition to the work item type definitions, the methodology template contains the Web portal template, process guidance, and process task instances. Each of these can also be customized by modifying the methodology template or creating a new methodology template.

Team Foundation raises work item events, and it provides an object model to automate tasks involving work items. The object model is suitable for use in a rich client application, or in a Web server application.

Source Code Management

The Source Code Management tool provides several ways to extend its features:

  • Add new types of check-in notes.
  • Add policies that are to be fulfilled prior to checking in code.
  • Add support for new file types.

A team might want to gather some specific information from developers when they check in code. Frequently, this is done either by adding comments to the check-in or by following up with a check-in e-mail notice. In both of these cases, all of the information tends to be only lightly structured. The administrator of the Source Code Management tool can add several types of notes that developers will fill out when they check in code. For example, a team might want the developer to provide the test impact and release notes. The test impact is used to flag the test team that they will have to take some action in response to the check-in. The release notes are used more generally to describe what was accomplished in the check-in. To enable this, the administrator adds two types of check-in notes to the Source Code Management tool—test impact and release notes. The administrator might also make release notes a required type of check-in note, but allow the developer to leave the test impact note blank.

Policies are conditions that should be satisfied before code can be checked in. For example, there is a policy that the administrator can enable that requires the developer to run static analysis prior to checking in his code. A team can also develop new policies by building the code that determines whether the policy has been satisfied, and then plugging that into the policy system.

The Source Code Management tool recognizes a set of file types and deals with them each in a way that is appropriate for that file type. By defining a custom file type, a user can control how the system computes deltas between revisions, how merge operations are performed, and whether the system allows multiple users to check out a file in parallel. ISVs whose tools create files that are likely to be stored in the Source Code Management tool may choose to provide a custom file type handler to enhance the user experience surrounding working with these artifacts.

Team Foundation raises events for source code management activity, and it provides an object model to automate source code management tasks. The object model is suitable for use in a rich client application, or in a Web server application.

Tool-Specific Extensibility

Each tool in Visual Studio 2005 Team System may be extended in ways that are specific to the tool's functionality.

Architecture and Design

The Architecture and Design tool provides a way to model systems and system deployments. Users can enrich the design environment with models of their own remote services for use in architecture designs, and hosting environments for use in deployment designs. Users can also add constraints to the design elements to make deployment validation more specific. For more information, see Visual Studio 2005 Team System: Designing Distributed Systems for Deployment.

Public Builds

Visual Studio 2005 Team System includes a tool to configure and execute public builds for the team. Users can add new types of build steps to the build process. They can also add annotations and rules so that the static analysis finds more defects. For more information, see Visual Studio 2005 Team System: Building Robust and Reliable Software.

Testing

Visual Studio 2005 Team System testing tools include facilities to build unit tests and other functional tests. The tests can be run locally, or they can be run in a distributed environment. Results of the tests may be used for individual evaluation, or they may be associated with a public build and published where they contribute to the test status of that build. Each test can also be incorporated into a stress test to help evaluate the execution characteristics of the application under load.

Users can extend the testing system with new test types. These new test types can be used to enhance the results view and add information to each test result and test log. For more information, see Visual Studio 2005 Team System: Enabling Better Software Through Better Testing.

Conclusion

The tools that make up Visual Studio 2005 Team System each provide ways to extend the capabilities of that tool. The APIs that each tool uses to integrate into the Team System and to provide specific integration with other tools are available so that teams can add their own tools to extend the capabilities of the existing tools. This allows teams and software lifecycle tool providers to add tools to the suite with the same rich integration found in the Team System tools.

For more information on Visual Studio 2005 Team System, see: