Team Foundation Architecture


Team Foundation is based on a modern, service-oriented, three-tier architecture comprised of a client, an application tier, and a data tier. The application tier is facilitated by an ASP.NET 2.0 web server hosted in an IIS6 environment. The data tier is supported by SQL 2005. The architecture of Team Foundation is optimized around the following basic assumptions:

  • A high bandwidth connection exists between the application and data tier.

  • The application tier and data tier servers can co-exist on the same side of a switch, which limits the impact their traffic has on the overall network.

  • Clients may talk to the application tier beyond the switch in possibly remote locations.

  • A combination of low bandwidth and high bandwidth connections exists between the clients and the application tier.

The following sections briefly look at the clients of the Team Foundation and explore the Team Foundation architecture. Following this, we'll illustrate the tight integration between the components of Team Foundation by walking through the process flow of Team Foundation Build. The data tier will be explored in part by taking a look at the Reporting Warehouse architecture.

Note

Although there are many interesting architecture areas in Team Foundation that can be explored (such as security), this section only addresses a few.

Clients of Team Foundation

Several clients ship with or are supported by Visual Studio 2005 Team System (shown in Figure 18-1).

image from book
Figure 18-1

The principal clients are the "role-based" clients of Team Suite that ship with Visual Studio 2005 Team System. These clients are Windows applications that run on Visual Studio–supported platforms. Additional Microsoft client applications have been integrated into Team Foundation Server, including Microsoft Project and Microsoft Excel. Although these clients are integrated into the Team Foundation server using managed add-ins, they can operate independently. One client that is dependent on Team Foundation is the Team Explorer. Team Explorer is a "bare-bones" Visual Studio–based client application for project management and analysis. As pointed out earlier, it provides user and administrative access to work item tracking, reporting, source code control, team project, and build management capabilities of Team Foundation. Team Explorer does not contain the language features and compilers of Visual Studio, or many of the modeling, development, and testing features of Visual Studio Team Suite. It is not considered one of the role-based clients. Internet Explorer can be used as a client to directly connect to the web-based Team Portal and the Team Reports.

Clients communicate with Team Foundation through a set of publicly available .NET-managed APIs exposed by the various object models of Team Foundation. This Team Foundation client-side architecture also enables third-party clients to easily integrate into Team Foundation.

Team Explorer

Team Explorer is a product with many hats. It's the name of a window in Visual Studio 2005 Team System, an add-in supporting Team Foundation Server functionality, and the name of a standalone client. When Team Explorer is installed in one or more of the role-based clients (e.g., Team Foundation Developers Edition), Team Explorer functionality is surfaced through a number of explorer windows in Visual Studio (e.g., Team Explorer, Source Control Explorer). For those nondevelopers interested in accessing Team Foundation features, a standalone install of Team Explorer is available. This is a thin- shelled Visual Studio-based client application for software project management and analysis and contains many of the same Team Foundation explorers exposed in Visual Studio logical architecture

Note

The Team Explorer window will be discussed in other sections of this book. The remainder of this section covers the client.

The Team Explorer client is targeted at those project leaders and analysts who want access to some or all the Team Foundation Server features but who:

  • Do not want to install Visual Studio 2005 Team System role-based clients, either due to cost or the install's heavy footprint.

  • Are developing using Visual Studio 2005 Professional or Standard Editions.

  • Wish to project-manage non-.NET software projects. Thus teams that may wish to do all their development on, for example, Java but wish to leverage the Project Management office tools, Work Item Tracking, Source Control, SharePoint, and even Team Foundation Build functionalities of Team Foundation Server, can still do so through the Team Explorer client.

  • Are developing using earlier versions of Visual Studio that do not have a Team Foundation version control Add-in.

Team Explorer provides the user and administration features of Team Foundation Server. Many of these are described as follows:

  • Reference an existing or create a new Team Project

  • Import and export process templates

  • Create, edit, and run queries

  • Connect to Report Server, create and view reports

  • Create and kick-off Team Foundation Build configurations, view Team Foundation Build summaries

  • Add/remove/modify Team Project groups and permissions

  • View and edit Team Project classifications and iterations

  • Launch the Source Control Explorer, edit Team Project SCC settings, view Pending check-ins

  • Add, view, and edit Work Items

Note

At the time of writing, a Microsoft Source Code Control Interface (MSSCCI) client is available for Visual Studio 6.0. (You can learn more about it on Brian Harry's weblog — http://www.blogs.msdn.com/bharry/.) Microsoft also announced the availability of a MSSCCI client for Visual Studio 2002 and Visual Studio 2003 around the time of Team Foundation Server's release. There are other similar interfaces for other development platforms including Teamprise for Eclipse, which will enable a Java developer to directly interface with Team Foundation Server.

Team Foundation Server services are exposed as ASP.NET 2.0 Web Services by an Integration Services layer. These Web services are optimized for high-latency networks for access by remote development teams. Each Team Foundation client accesses each Web service through a proxy with an easy-to-use Team Foundation public API, as shown in Figure 18-2.

image from book
Figure 18-2

Integration between Team System and third-party components and services can be categorized in terms of user interface integration, process extensibility, and data integration:

  • User interface integration is facilitated through the Visual Studio Industry Partner (VSIP) program. VSIP enables third parties to plug services and products into the Visual Studio Integrated Development Environment (IDE).

  • Process extensibility is provided through the use of methodology templates. These templates define the process that individual projects will follow. Customers and partners will be able to create new process templates or customize out-of-the-box process templates for their own projects. Process extensibility can include customization of work item types, custom reports, check- in policies, and project management templates. Project Creation Wizard (PCW) plug-ins allow the process to be customized further.

  • Data integration is handled between the Team Foundation Application tier and its clients using a collection of Team Foundation object model (OM) public interfaces. Each Team Foundation component has a complementary pair of OMs. For example, a WIT client-side OM communicates to an application tier WIT OM using ASP.NET 2.0 Web services. Within the Application tier, a common set of integration services, called the Team Foundation Core Services, ties these components together. The Application tier then communicates the data to the Team Foundation Data tier using MSSQL. Finally, the data is read or written to the appropriate SQL 2005-based data store. The overall Team Foundation Server architecture is illustrated in Figure 18-3.

image from book
Figure 18-3

All Team Foundation Data Tier data is managed by SQL Server 2005. This means you can use SQL methods to handle backup and recovery and SQL clustering/mirroring for data tier failover. (Note that for data migration between VSTS product versions, VSTS supplied scripts will be necessary.)

A few of the Team Foundation Core Services are particularly notable:

  • Notification & Eventing Service: A publish/subscribe synchronous or asynchronous system for event notification. Users and other tools and services can subscribe to those events it may raise.

  • Linking Service: Enables loosely coupled linking between tools' data using URI-based links

Team Foundation Build

To illustrate the high level of integration between components of Team Foundation Server and Team System role packages, we'll provide a short introduction to the Team Foundation Build architecture and process flow. Before we dig into the features, let's briefly discuss what exactly is Team Foundation Build.

The goal of Team Foundation Build is to provide a "build a lab out-of-the-box" experience. A conventional build covers many steps, such as cleaning the remote build machine, obtaining the sources from the build machine, compiling the source, running tests against the build, either before or after the build, and communicating the results of the build back to the team. Most build scripts cover these steps, but getting a solid build process up and running reliably is often more of a chore than you or your team would like to face. The poor integration of the tools involved in this build process often results in a weak software life cycle experience.

Team Foundation Build solves this problem by automating these traditional build steps using wizards supported by Team Explorer. These wizards enable users to easily generate and kick-off fully extensible XML scripts for the Visual Studio Build engine called MSBuild within a well-integrated infrastructure.

Team Foundation Reporting Warehouse architecture

The Team Foundation Reporting Warehouse is a conventionally organized data warehouse where data from third-party tools and Team System plug-ins (e.g., version control, WIT, builds, testing tools) can be stored. Data from these tools and plug-ins is published, either manually (for test data) or as part of an application tier Team Foundation services, to a number of relational databases, located on the Team Foundation data tier, called operational stores. These operational stores are optimized for online transaction processing and have names like TfsVersionControl and TfsWorkItemTracking. Periodically, data is pulled from these stores through warehouse adapters. Each operational store has its own adapter whose task is to transform and publish data in a standardized format to a relational database, called the Team Foundation Relational Warehouse (TFSWarehouse). On top of the Relational Warehouse is an OLAP cube that further aggregates the data for end user and prebuilt reports.

A number of tools can be used to build reports from this cube. Microsoft Excel can be used by project managers to access the cube directly and build ad-hoc reports, possibly for exploratory analysis. Report Builder is a tool that comes with SQL Server 2005 Reporting Services. It can be used to create reports by dragging and dropping OLAP fields onto a design surface. For specific layout and formatting requirements, the Report Designer tool from Visual Studio 2005 can be used. This tool allows you to interactively design a report by using data from Team Foundation as a data source. The Team Foundation Reporting Warehouse architecture is shown in Figure 18-4.

image from book
Figure 18-4

The operational stores are organized in a star schema with an OLAP database that draws from the Relational Warehouse schema. A star schema is the simplest data warehouse schema that can be used. At the center of this schema is a "fact" table that lists the core facts that make up the Report query. Each fact is composed of the following: dimensions, used to slice the data in a report; measures, things that are counted or aggregated; and details, the columns that appear in the relational table.

The Reporting Warehouse uses a single OLAP cube with a measure group per fact to assemble the data from the star schema. Examples of measure groups are Work Item History, Test Results, Code Churn, and more. This enables reports drawn from the aggregation of data to end up being simple selects. For complex queries, an answer can be produced in OLAP in about 0.1 percent of the time it takes for the same query on relational data.

The Reporting Warehouse architecture enables each Team System tool to submit data to the warehouse schema and transform the data. For example, when a load test is run, the results are published to a local results store (e.g., SQL Server Express database). The user can elect to manually publish these results (assuming the user has installed Team Foundation Client) to an operational store. This store has a schema that reflects the type of data the Team System load test tool generates. A Reporting Warehouse service on the application tier (called TFSScheduler) periodically sweeps the data stores every hour (by default) and tells the Warehouse Controller service to run adapters. Each of the registered warehouse adapters are then engaged by the Warehouse Controller service through methods on the IDataAAdapter interface. These adapters, represented by managed code running outside of SQL 2005, filter, transform, and move the data to the Team Foundation Relational Warehouse. For example, the LoadTest adapter provides the Team Foundation Relational Warehouse with an "average" of all the counter metrics collected by the operational store.

Note

Team Foundation links work items and code files back to requirements that may be outlined in documents stored in the Reporting Warehouse. This integration enables a modest form of a requirements traceability matrix, essentially coverage analysis that provides a birds-eye view of how much of the requirements are being covered by tests or being worked on in design or development. Such mapping is an important tool for large development shops.

Configuration

You can configure Team Foundation Server deployments on one machine (application and database tier together) or two machines (application and database tier separate). This is illustrated in Figure 18-5. An additional server may be added to the configuration to support building. Another server may be added to enable version control proxy support. As of this writing, a two-server install (separate application and data tiers) with the following configuration will support teams of up to approximately 2,000 users:

  • Application tier: 2P 2.8 GHz 4GB

  • Data tier: 4P 2.7 GHz 16GB

  • Disk system: Direct attach storage, 14-15Krpm RAID 0 spindles

image from book
Figure 18-5

The application tier and data tiers DT servers require Windows Server 2003 SP1, and have a dependency on IIS 6.0, Windows Sharepoint Services 2.0 with SP2, and SQL Server 2005. Team Foundation–enabled clients require Windows 2000 SP4, Windows 2003 SP1, or Windows XP SP2. These clients also will have a dependency on Internet Explorer 6.0, Microsoft Office 11 with SP1 (Office 2003), NET Framework 2.0, and of course Team Explorer.

The Team Foundation Proxy requires Windows XP SP2 or Windows 2003 Server SP1, and .NET FX 2.0.

Please refer to the Team Foundation Server setup instructions for additional hardware and software requirements.



Professional Visual Studio 2005 Team System
Professional Visual Studio 2005 Team System (Programmer to Programmer)
ISBN: 0764584367
EAN: 2147483647
Year: N/A
Pages: 220

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net