Customizing Visual Studio 2005 Team System Using Process Templates

Visual Studio 2005 Team System uses process templates to automate the configuration of new VSTS projects. Simply put, a process template tells VSTS step by step exactly how to set up a new project. In a very direct way, the process template defines the methodology for a project by specifying which process tools will be used and how those tools will be configured for the project. The process template even installs the project's process guidance documentation.

The truly marvelous thing about a process template is that a team can take an existing template and customize it without having to do any programming or use any proprietary tools. This flexibility enables the team to build its own processes into VSTS and then improve those processes over time based on lessons learned.

VSTS comes with two process templates: Microsoft Solutions Framework (MSF) for Agile Software Development and MSF for Capability Maturity Modeling Integration (CMMI) Process Improvement. These templates can be used as-is or customized as needed.

Figure 9-1 shows the structure of the process template for MSF for Agile Software Development. Notice that there are XML files throughout the template. These files are called Process Definition Files. These files tell VSTS which Process Template Plug-Ins to use and also define the sequence of tasks the Process Template Plug-Ins should perform. The subdirectories contain other tool-specific files, most of which have been omitted from the figure for clarity.

Figure 9-1

Process template-MSF for Agile Software Development

Process Template Plug-Ins are components that VSTS uses to create a new team project. Each plug-in plays a specific part in the setup process. Microsoft provides six plug-ins with Visual Studio 2005 Team System, as shown

Process Template Plug-Ins

Customizing the Process Guidance Documentation

The MSF for Agile Software Development process template automatically creates a SharePoint Web site containing, among other things, the process guidance documentation. Teams might want to edit this documentation to more accurately reflect their development process. The process guidance Web pages are generated from an XML file call ProcessGuidance.xm l, which is transformed to HTML for display in a Web browser. You can edit this document with an XML editor like the one in Visual Studio.

Team Foundation Server Extensibility

Each tool offered in Team Foundation Server is highly customizable and can be automated. Work item definitions, source control policies, build scripts, process templates, and programmability interfaces all enable customers to tailor their Team Foundation Server installation to their needs. In addition, at the core of Team Foundation Server is a set of mechanisms intended to enable partner- and customer-written tools to integrate into the Team Foundation Server environment as first-class citizens.

Team Foundation Server's shared services are detailed in the following sections.

Linking Service

The linking service enables tools to establish loosely coupled relationships ("links") between data elements they hold. For example, in Team Foundation Server, the relationship between a defect work item and the source code that was changed to fix the defect is held as this sort of link. To participate, a tool must implement methods that expose their data as Team Foundation Server "artifacts," and it must respond to queries against them. Using this facility, a tool can participate in a relationship that it wasn't initially designed to recognize.

Security Service

The security service implements groups of Microsoft Windows identities within Team Foundation Server. These groups, local to a Team Foundation Server, are used to assign permissions to Team Foundation Server artifacts and services. The groups can be administered without the help of the IT department. When a new tool is introduced to Team Foundation Server, it should respect these groups by using the group security service application programming interface (API). The security service also provides authorization services. Tools that do not offer their own authorization mechanism have the option to use the security service to secure objects and establish permissions.

Eventing Service

The eventing service is a Web service-based publication and subscription mechanism. As expected, tools can raise events to the eventing service. Subscribers can register to receive notification when an event matches their subscription criteria. A notification recipient can either be a Web service or an e-mail address. When it's a Web service, the subscription includes the URL of a Web service to be called when a notification is to be delivered. When it's an e-mail address, a notification can be delivered through e-mail via an SMTP server.

Classification Service

The classification service works in coordination with the linking service to allow classification of Team Foundation Server artifacts according to predefined taxonomies. This enables tools whose artifacts do not share a common "natural" taxonomy to organize their data in such a way that cross-tool reporting along common axes is possible. For instance, if work items are naturally organized by team and tests are naturally organized by component, tests can additionally be organized by team to enable them to be reported alongside work items.

Registration Service

When a new tool is introduced to Team Foundation Server, its artifact types, link types, event schemas, and service interfaces are registered via the registration service. Clients of the new tool discover its location by asking the registration service. Client configuration is easier because the client only needs to know how to find the registration service. This also makes it easier to move services from one host to another, as the registration service will redirect clients as needed.