Getting Started With Microsoft Visual Studio Team System 2005

1.0 Introduction

As Microsoft follows their tradition of giving birth to new exciting products and technologies, it's getting more and more challenging to cope with this cutting edge pace. This article is aimed at all those people who are part of the SDLC life cycle in one way or another includes but not limited to the following roles:

• Project Managers
• Solution /Software Architects
• Software Developers
• Software Testers
• QA Executives

I understand that the above list of roles is quite long but this is why getting started with Visual Studio Team System and Team Foundation Server is bit more time consuming and demanding than other Microsoft products in the market, such as SharePoint Server or BizTalk Server. They are part of a specialized domain. With VSTS and TFS you need to understand bits and pieces of knowledge from multiple domains. The point to note here is that understanding how VSTS and TFS work will help you do your job better.

This article will be followed by a series of articles where a specific component of VSTS & TFS will be explored in great detail. This is very intentional as no single article can do justice to the product and many components require much more detailed explanation than I can put here. So when you are reading the article keep in mind that you are basically getting an overview of the product. Right now it's important for you to know what VSTS & TFS is, what the basic components are, and what they encapsulates — the in-depth details can wait a bit.

As an analogy, think of a CSI (TV Series) investigation. First they pay a visit to a crime scene and collect evidence. It's later that they drill down to nifty details (and of course a lot of geeky talks, autopsies, and sometimes if we are lucky a car chase in a Hummer!).

1.1 What Are VSTS and TFS

So first thing's first, what exactly are VSTS and TFS and why would you ever want to use them? Simply put VSTS is the expansion of Visual Studio Product line that encapsulates a plethora of new features and tools for all of the roles in SDLC (Software Development Life Cycle).

Since its launch, Microsoft Visual Studio (.NET or even previous versions) has been more directed towards Developers. Regardless of if you want to write VB code or develop an application, VC++ Visual Studio is the tool that all developers use alike. Microsoft puts whole team into a one big interactive, collaborative environment and provides them the landscape to get more out of technology. The good news is that if you have any background of using Visual Studio then this new learning is pretty quick and smooth.

Team Foundation Server (TFS) acts as a big backbone repository, and provides a number of functionalities including versioning, team building, etc. The best part is that once the TFS is installed (properly of course) it can cater to specific job roles. If you are bit overwhelmed by too many things in one product, don't worry because you are going to see how things gel together to form a cruise for collaboration.

Let's take a look into the architecture of Team Foundation Server and examine its components. Understanding this will provide you with a good ground for working with the product, specifically if you later want to do some customization, extension or even maintain the TFS deployment.

1.2 Team Foundation Server Architecture

Microsoft Team Foundation Server (TFS from now on) is basically comprised of 3 tiers: Client tier, Application tier (usually called App tier for short) and Data tier. This is shown in Figure 1.2.0. This layering provides easy administration, extensibility and scalability. This also enables a different installation configuration for TFS, which you might be really interested in if you want to deploy TFS in a large organization. Let's take a closer look at each layer and examine how it fits into the whole architecture.

1.2.1 TFS Client Tier

This is the topmost tier and comprises various components for a variety of roles in SDLC. All of these components are using Team Foundation Client API written in managed .NET code and exposed by the object model of the Team Foundation Server. One of the most prominent of these components is Microsoft Visual Studio 2005. Microsoft came up with a component for each major role in SDLC. Microsoft has released what is called Visual Studio Team System (VSTS in short). So we have all these specialized features: Visual Studio Versions for Team Developer, Team Architect, Team Tester and Data Base Professional. The point to note here is that these entire components use TFS client API's which is 'publicly' (though one might want say the word 'open', but let's not do that!) available. What this essentially means is that this provides a very powerful yet uniform way to develop custom extensibility points that can be integrated with TFS.

1.2.2 Office Products

One of the other client components is Office Products (Excel, Project), this provides a convenient way for non Visual Studio-inclined users in roles like Project Manager (practically the chances that someone working in the roles of Project Manager and Software Developer at the same time are almost mutually exclusive) or Quality Assurance (QA) to use product like Microsoft Excel or Project to leverage TFS Features. Figure 1.2.1 shows use of Microsoft Excel to integrate with TFS.

The Toolbar in the Figure 1.2.1 is magnified and shown in Figure 1.2.2. Notice that this toolbar contains all of the basic required features by the role of Project Manager or Team Lead to connect and communicate with TFS. The good news is there are many other similar connectivity components that are freely available on the web. One which might interest you is Microsoft Project Server 2007 Connector for TFS which allows to connect to TFS from Project Server 2007. For all those who want to know about Microsoft Project Server 2007 Connector and many other tools for TFS, visit CodePlex and you will find many interesting and useful components for free. In addition, for most of them the source code is also available.

1.2.3 Others Products and Team Explorer

There can be many reasons why non developers might not want to use Microsoft Visual Studio (VSTS) to access TFS. One of the most common is cost in-occur by VSTS and that's why a lot of small organizations stick to other modest Visual Studio 2005 versions, or even for that matter, older versions (like VS.NET 2003 or VS 6.0). One interesting situation is how I can connect to, and use, TFS while using some other technology or product from IBM or Sun! This is where Team Explorer comes into the picture.

Microsoft analyzed that there can be many scenarios and situations when there is a need for accessibility to TFS outside Microsoft Product Suites (this includes both Visual Studio and Office Suite). Team Explorer serves many purposes, like in the situation above where Team Explorer can be installed as an independent component and facilitates you to access all (or subsets) of TFS Features. The other option is that you can install it as a shell or component window (like Solution Explorer) in VSTS. This gives you an excellent way to access TFS while working in an environment that suits you. Team Explorer installs for all VSTS flavours like VSTS for Testers, Architects and Developers). Figure 1.2.3 shows the Team Explorer.

1.3 Application Tier (App tier)

Next to Client tier is Application tier, this consists of a number of components. Let's examine them one by one.

1.3.1 TFS Integration Services

Integration services are essentially TFS services that are made available through web services (to be more accurate these are ASP.NET 2.0 web services and that's why IIS 6.0 installation is mandatory for application tier). The integration services acts as a hub or access point for client tier components that connect to these services via proxy. This again is facilitated by use of TFS public API. We can categorize these services into TFS Core (see Figure 1.3.1.1) and Data Services (see Figure 1.3.1.2). Let's briefly touch each service (the future articles on TFS will provide acute treatment on each of them with examples but for keeping things simple only a brief description is provided here).

Linking services provides a way to link or associate one component (artifact to be exact) from number of sources. Think about it as a service that allows you to create loosely coupled relationships between the data elements.

Classification services is the one that lets you know the whereabouts of Team Project itself, like team Project Name and URI (you can access these from Team Project). This is quite useful when you want to develop your custom tools to access the Team Project and edit it.

Registration Services routes the calls to TFS such that they are mapped to correct services and tools. In fact you can query the TFS using the TFS OM and get details of tools that are registered to TFS.

Security services enables you to work with security in TFS. This includes managing users and groups along with the memberships to the groups and ACL (Access Control List).

Eventing Services provides you with the option to become a subscriber of a number of events that TFS supports. This is essentially helpful for those who are interested in specific events and want to take custom actions when an event occurs. For example, an event is generated when TFS Build is completed. This can help a Configuration Manager to do a series of tasks when he/she is notified. For notification a user can opt for an email or suggest a web service that TFS will trigger when an event of interest occurs.

TFS Data Services (see Figure 1.3.1.2) are web services that provide methods to access and manipulate the data located in data tier.

Version Control services enables you to work with a TFS version control database and other features of source control.

Work Item Tracking lets you work on custom tools that need to manipulate work items in the WorkItem Tracking database.

Team Foundation Build Service enables you to execute the build process (see section on TFS Build for more information on what is TFS Build). The MSBuild Framework also leverages this service.

1.3.2 TFS Reporting

Team Foundation reporting is based on Microsoft SQL Server 2005 Reporting Services, SSRS (this is one of inherent advantages of using Microsoft SQL Server 2005). The reporting provides some excellent insight of what is going on with the project and this is not only informative for Project Managers or Team Leads it also enables developers or testers to keep eye on bug rates and release delays etc. Microsoft provides many out of box reports and once the project is underway these reports act as indicator of how the project is going on with a good amount of detail. These reports include Bug Rates, Builds, Quality Indicators, Project Velocity and Issue Lists, following diagrams show some of the out of box reports in TFS.

Remaining Work: How much work is left and when will it be done?

Quality Indicators: What is the quality of Software?

Project Velocity: How do the resolve and close rates compare?

Of course there will be times when you have requirement to create custom reports, this is also fully supported, if you have any experience of making reports for SSRS 2005 in VS.NET you will feel right at home, but there are also other options for creating custom reports including Report Builder (for those who don't know what Report Builder is, it is a Click Once application that is integrated with SSRS and provides powerful way for users to develop reports quickly).

1.3.3 Team Portal

Team Foundation Server uses Windows Share Point Services 2.0 (WSS 2.0) for all kinds of portal operations. There is one WSS 2.0 site dedicated to one TFS Project (if you don't know much about WSS 2.0 read this article. Though an understanding of WSS 2.0 is not mandatory, you will have to dig into its architecture and basic features in order to even maintain or extend a simple TFS Portal. Moreover, in most TFS deployments Portal Customization and Custom Development is required). Let's take a quick tour of Team Portal and look at the prime features that are available in it.

You can browse to Team Portal by using Team Explorer (both from inside VSTS or outside as an independent application) see Figure 1.3.3.1 that shows this option.

This will launch the team portal in the default browser, see Figure 1.3.3.2.

This portal is the starting point for everyone in your team and all the relevant stakeholders. This portal contains Documents, Reports and project guidance and this is all by default when you create the new project. If you notice the top banner of this site you notice MSF for Agile Software Development (for now it's enough to know that this is one of the Default types of Team Projects that you create, the other one is MSF for CMMI, and of course you can create your custom Project Templates), there is in fact a whole process guidance for default methodologies provided by TFS. You can click on the Process Guidance link to explore it, see Figure 1.3.3.3.

The important point to keep in mind is WSS 2.0 and TFS web services will use the same IIS 6.0 so you must confirm that they are configured on different ports.

1.3.4 Team Build

Team Build or Team Foundation Build is a component that helps to automate the whole build process which you can also schedule as you want. Team Build lets you fetch the code from your TFS source, build and test it and then store the resultant build (binaries and some other files) at a location known as Drop Location (which is a network share location). Once the build process is done you can view the reports against the build which gives you an up-to-date and concise picture of how the build performs. At this moment if you are thinking how all this works you will be surprised that Team Build uses Microsoft MSBuild (which is XML-based) to automate the build process. In fact, it is present in the .NET Framework as a core component. To be honest with you, if you want to dig deep inside Team Build, prepare yourself to delve inside MSBuild to twist and tweak the XML that resides within it. Team Build is launched through Team Explorer (see Figure 1.3.4.1). Once you click the New, Team Build Type option a wizard will be launched which will let you set up the whole build process see Figure 1.3.4.2.

By the way, one important thing to remember is that you need at least one code project (C#, VB.NET, etc.) to exist in source control on which you will perform the build process. There is one very useful option that you may want to use and that is to be notified once the build process is finished or build status got updated. Within Team Explorer chose a Team Project and then right click it and select Project Alters as shown in Figure 1.3.4.3.

This will open Project Alters windows (see Figure 1.3.4.4). Here you can select an event on which you want to be notified. You can enter the email address in, send to column, and select the format in which you want to view the alerts which can be either HTML or Plain Text.

At this point there might be number of questions that are popping up inside your mind, so the following is the list of items that mostly occur when you start implementing team build.

1. What happens if I have a pre .NET code base (VC 6, VB 6, etc.) or a pre .NET 2.0 code base to build
2. How can I integrate Third Party Products?
3. A need build process that is fully compatible with some industry (e.g. ISO) or custom made standards.
4. Setting up Build on multiple servers.
5. What Command Line tools are available for team build, specially for administrative tasks?

Honestly, all of the above mentioned questions require thorough treatment on Team Build (and MSBuild) with a complete drill down on details, which will be done in future articles solely dedicated on team build. Right now for overview purposes it's quite fair to get the basic idea team build.

1.4 Data Tier (DT)

Microsoft TFS Data Tier resides on SQL Server 2005 (continue with their classic trend of using SQL Server as a back end, for those who are wondering check out MOSS 2007, BizTalk 2006 and MCMS 2002 just to name a few products). Tough TFS uses SQL Server 2005 as a Data Tier you are not allowed to directly access the TFS databases (tough, sometimes you really want to, so I have to say here bend the rules but don't break them). One of the prime reasons for not allowing direct access is the change is TFS databases schema that may occur in future releases of TFS and that will only break your current work if you have any code or a query that made direct access to the TFS databases. In order to access the databases you need to use the TFS Data Services (see section 1.3.1) present at application tier. TFS data tier consists of a number of data stores and to add more power to it Microsoft has provided a Data Ware house to fulfill your advance reporting needs. The following are the list of databases (see Figure 1.4.1) that are present at TFS data tier.

As you can see in the figure that most of them correspond to the TFS major feature set (e.g. work item, version control, Build, etc.), this is in fact the case. TfsActivityLogging is used to store even logs of version control, TfsBuild contains all the build data, TfsIntegration is for TFS core services (event, notifications, etc.), TfsVersionControl is a sole repository for a TFS Version Control, TfsWarehouse is a dataware house for performing online analytical processing, TfsWarehouseExtension is for maintaining extensions to the warehouse, TfsWorkItemtracking is responsible for Workitem Tracking, and finally, TfsWorkItemTrackingAttachments is aimed to store Workitem Attachment.

Now this is first time Microsoft provides such a build in Warehouse in any its stream line products (like TFS). The data from the databases (called Operation Stores) like TfsBuild , TfsversionControl, etc. is fetched on periodic bases and put into the data warehouse. This is done by using what is known as Warehouse Adapters. Each operational store has its warehouse adapter which helps it to publish data to TfsWareHouse.

If you're thinking that this exercise is futile, think about the response time of the complex queries. You will be amazed how quickly complex queries produce results when run against data warehouse. Moreover, there are more chances that usage of TFS in your organization grows with time and operational stores become more and more populated this approach will help you out to work even with gigantic size stores.

Maintaining half a dozen databases is not an easy task but SQL Server 2005 made it really convenient (it's not a piece of cake for that matter) to do so. You can leverage the SQL Server 2005 features like clustering, log shipping, mirroring to sort things out for you.

Where We Are

In this article we take an overview of what VSTS and TFS are and their basic architecture and core features. TFS along with client end product suites provides excellent opportunity towards better and more controlled SDLC. In the next article we will look into the client suite of products that leverages TFS. This will be mainly VSTS with a focus on specific job roles like Architects, Developers, Testers, Data base Professionals and Project Managers.