Visual Studio 2005 Team Foundation Server

Visual Studio 2005 Team Foundation Server

Starting at the heart of VSTS, Visual Studio 2005 Team Foundation Server (TFS) provides its core back-end infrastructure. TFS isn't required to run the various Visual Studio 2005 Team editions, but without it teams won't collaborate as well as they could. It could be said that Team Foundation Server is to Visual Studio 2005 Team System what Exchange Server is to Microsoft Outlook.

Team Foundation Server Components

Team Foundation Server is primarily used in environments where teams need communication tightly integrated inside Visual Studio, scalable source-control software, and an integrated Web portal. In short, it most teams will benefit from the features that Team Foundation Server provides.

Team Foundation Server provides solutions such as

Project management-Create and manage team projects

Work item tracking-Create and manage requirements, tasks, and bugs

Change management-Source control to manage changes to the project

Build server-Automated and extensible project-build tool

Project site-Windows SharePoint Services portal to list documents and reports

Reporting-Make management and status reports available to the entire team

These are important features to teams of every size and serve to unify the entire team in various ways. Without Team Foundation Server, each team member would be architecting, developing, or testing within his or her own environment separately from the rest of the team.

Team Foundation Server Architecture

Team Foundation Server provides a multi-tiered architecture, composed of an application tier and a data tier. It is similar to what many organizations are also building in-house for their own line of business applications, and utilizes best-of-breed software, such as ASP.NET 2.0 and SQL Server 2005.

Data Tier

Team Foundation Server's data tier is hosted on SQL Server 2005. An advantage of TFS being hosted on SQL Server 2005 is that it becomes a central place to maintain and back up all assets in the database, also taking advantage of other availability features such as database mirroring and clustering.

The following databases are installed in the data tier:

BisDB

Team Foundation Server core services (project metadata, notifications, security groups, etc.)

BisDWDB

Team Foundation Data Warehouse

CurrituckDB

Team Foundation Server work item tracking database

VSTEAMSCC

Team Foundation Server version control source

VSTEAMSCCAdmin

Team Foundation Server version control event log

VSTEAMTeamBuild

Team Build data (results, code coverage, test results, etc.)

Reporting Services

Another benefit of hosting TFS on SQL Server 2005 is the built-in reporting capability using SQL Reporting Services. This technology is available out of the box with SQL Server 2005 and is the cornerstone to VSTS's informative, real-time reporting with over 20 reports which can be readily run. These include many beneficial reports that pull from the data warehouse, such as project health, code churn (changes in code between checkins), test pass, test effectiveness, active bugs, and efficiency reports. Figure 2-1 shows some of these reports, which are available directly from the Reporting Services report manager portal. With just a little knowledge of the database structure and some experience with authoring Reporting Services reports, any team member can create the custom reports needed. These reports can, in turn, be displayed through the project portal by using a Microsoft Windows SharePoint Services reporting Web part.

Figure 2-1

The reports available in VSTS

Application Tier

The application tier is composed of ASP.NET (ASMX) Web services, which are called from the various client applications as well as Windows SharePoint Services.

The following ASP.NET Web services are installed in the application tier and correlate roughly to the database tier.

bisserver

Application Programming Interface (API) for the Team Foundation Server core services

SCC

API for the Team Foundation Server version control

TeamBuild

API for Team Build

Warehouse

API for Team Foundation Data Warehouse

WIT

API for Work Item Tracking (as shown in Figure 2-2)

Figure 2-2

A Web service that tracks work items

Windows SharePoint Services (WSS)

WSS plays an integral part of TFS providing the team portal framework. Using the in-built productive features WSS provides allows team to upload, download, check-in, check-out, and version without developing custom applications, or learning new techniques. WSS is a natural fit for Visual Studio 2005 Team System. Figure 2-3 shows an sample team portal.

Figure 2-3

A Windows SharePoint Services team portal

Client Tier

The client tier of Team Foundation Server includes the many various client applications that organizations may be running. Client applications can communicate with TFS via Web services. This allows for multiple clients from Microsoft, third party partners or more importantly custom clients interacting with the client object model or accessing the Web services directly.

Visual Studio 2005 provides out of the box the following client integration

Visual Studio 2005-The latest edition of Visual Studio, which many development teams already use

Microsoft Office Excel-Popular spreadsheet software, which is part of Office

Microsoft Office Project-Powerful project management software

Internet Explorer-A browser that allows all team members access to the team portal

Team Foundation Client-A lightweight, standalone tool for managing projects

Software Configuration Management (SCM)

Software configuration management can be a large problem for many organizations. Companies and teams that lack insight into how to integrate their projects can be headed for failure. Using an effective software development tool with built-in SCM enables a team and company to manage the unmanageable.

VSTS improves team's SCM in the following ways:

Enables the developing and managing of multiple versions of a product at the same time

Enables multiple developers to work on the same files simultaneously

Merges changes from one release to another

Relates bugs and bug fixes back to their origin

Manages software builds

Manages releases

Improving team communication is a great start for solving problems related to design and development. Team-based software development is like an orchestra during a symphony, where all the members need to be in synch, watching their manager, and working in unison to bring the deliverable to fruition on time. Managers regularly need to know what state the project is in, how much code churn is in the nightly builds, when the project has reached zero new bugs, etc. Requiring team members to pull out of their task and commit time to answer these questions can be quite distracting and hurt overall productivity.

Depending on the methodology chosen, the actual software development approach might be quite different. Ultimately though the need to intelligently store information will be the same as any other team. Teams must constantly manage repositories of requirements, tasks, source code, bugs, and reports. Scattering each of these item types to different tools fractures the already brittle communication pathways of teams and software.

A sample VSTS's core concepts of software configuration management can be:

Work item tracking

Source code control

Build and release management

Team communication

Reporting

Work Item Tracking (WIT)

The term work item abstracts or generalizes the various concepts of software development. A work item can define any actionable unit of information that is part of the software development life cycle. Examples of work items include requirements, tasks, and bugs. Work items have properties, such as title, date, status, and name of the team member they are assigned to and are the foundation of the software process. As teams pass through the various phases of the life cycle, the work items move with them.

The actual type and format of work items is dictated by the methodology chosen for the project. A powerful feature of work items is the ability to link them to other artifacts, which is key to an effective SCM strategy. Linking a work item to a set of code checked into source control allows the developer and the project manager to track which changes are related to which requirements or bugs. Tough questions such as, "Why was the change made?" and "Who authorized the change?" can now be easily answered. All these linkages can be queried and reported. This information is displayed clearly on the Links tab of a work item.

One of the most powerful components of VSTS, is the ability for members of the teams to use the tools that are comfortable using. For example, if a project manager is already tracking bugs and requirements in Microsoft Excel or Microsoft Project, they should keep doing it. By using the integrated VSTS toolbar, they can synchronize work items, modify (even offline) and synch any changes that will be immediately reflected in the TFS database.

Customizing Work Item Tracking

Microsoft understands that the work items that are developed for the MSF methodologies won't satisfy everyone's needs. Organizations may want to utilize their own custom methodologies, or add/delete/extend the current ones.

VSTS allows users to add, edit, or delete the actual work item properties, including how they appear in the user interface and any rules and workflow associated with them. These new or altered work items will surface in the various tools and reports, throughout they development process based on the methodology templates, just like those work items provided by default.

Source Code Control

Team Foundation Source Control (TFSC) is a complete new application built from the ground up, providing a multitiered architecture and, as such, offering the same benefits as those enjoyed by the work item tracking architecture. Organizations which are familiar with Microsoft Visual SourceSafe, will be comfortable with the similar look and feel and be able to adopt a larger more rich feature set. Team Foundation Source Control has been primarily developed to support large, distributed development teams and projects.

TFSC introduces a new concept called a changeset. With other source control products, the individual files they were working on had no linkage or context. They were just separate files checked in at the same time, and hopefully commented enough to give them context and glue them together. Changesets describe a group of associated file modifications. This allows for better accounting and workflow, as well as simplified administration. Each changeset is given a unique identifier for tracking and reporting.

As the developer works on the files under source control, the changes are made to the local workspace. Later, they can check them in, specifying any required documentation and associating the changeset with any work items.

If organizations have both Visual SourceSafe and TFSC installed, users can switch back and forth by selecting different plug-ins. This way, users can continue to support legacy or Visual SourceSafe projects, as well as any new development efforts under the Team Foundation Source Control. (See Figure 2-4) Microsoft will also be producing a migration tool to move Visual SourceSafe artifacts over to Team Foundation Source Control upon release. There is also a command-line utility (h.exe) for checking in and checking out documents. This utility allows interaction from any environment, not just Visual Studio 2005.

Figure 2-4

Choosing source control plug-ins inside Visual Studio

TFSC building on the capabilities of Visual SourceSafe also provides three new features; branching, merging, and shelving.

Branching

Branching in TFSC is similar to copying items from one project to another; however, it is performed with greater tracking information. The origin, context, and history of the copied items are maintained so that future changes can be merged back into the original path. This capability is important to SCM as it allows multiple builds and releases to be maintained efficiently. These branches are easy to visualize and navigate in the Visual Studio Source Control Explorer and enables a developer to work simultaneously on many branches of the same code, as is sometimes necessary.

Branching can be performed by date, label, or version. Developers can branch from an existing project in the Source Control Explorer (as shown in Figure 2-5) or when they begin a new team project (as shown in Figure 2-6). All changes which are made to the newly branched code are performed locally, in the local workspace, until they are checked into TFSC. The advantage of this process is that they can make any necessary changes, build the code, and test it to make sure it works properly before checking it back in as a new branch.

Figure 2-5

Creating a new branch from Source Control Explorer

Figure 2-6

Creating a new version control branch at project creation

Another benefit of branching is that of storage space efficiency. The source control server can minimize the required storage by only maintaining one copy of content, regardless of how many source files contain it. This is similar to how Exchange Server keeps only one large, attached file even though it's being sent to many people. For example, in TFSC, only one copy of a 3-MB file will be saved even when there are 10 copies of the file in various projects and branches. For this reason, new branches consume very little space. As the developers start making changes to particular files, the additional storage will be used for those changes. Team Foundation Source Control stores only the differences, or deltas from the original files.

Security can be configured on these branches just as they would set permissions on any directory folder in Windows. Branches are essentially paths, so they can use the same access control list (ACL) security that many organizations as used to. Just right-click on a branched folder, choose Properties, and set the permissions.

Merging

Merging is at the core of TFSC's efficiency. This highly intelligent process reconciles all the changes made in branched code ("the source") with its original code ("the target"). This is why TFSC remembers the origin and relationships when branching. Merging is more than just blending text, it's almost transactional in nature, because it will merge additions, deletions, un-deletions, and renames from the source to the target environment. It's similar to the concept of Merge Replication in SQL Server.

VSTS projects can be configured for multiple checkout. This feature allows more than one user to edit the same file simultaneously. The same engine that merges changes between branched projects can also merge changes from two or more checked-out projects back to the source.

Organizations can choose which changes they want to merge. For example, they can merge the code which fixed a single bug without merging anything else that they were working on. After merging, TFSC updates the merge history for the items. This information is tracked automatically and can be viewed from inside Visual Studio or accessed from the command-line utility.

Shelving

Shelving is another new, key concept to TFSC. Shelving allows a developer to store their pending changes to the server without checking them in. TFSC introduces the concept of a shelveset, which is similar to a changeset except that it's used to store files in a personal space on the server. Users can upload pending changes, comments, and associated work items to this personal space which allows for full maintenance, backup and disaster recovery whilst they work. Figure 2-7 shows the shelving feature from inside Visual Studio.

Figure 2-7

Shelving code from Visual Studio

There are many reasons that a developer may want to shelve code, including the following ones:

They need to switch to a different project to perform work with higher priority.

The code fails a check-in policy, and can't fix it immediately.

The code is not complete enough to share with others.

They need to leave suddenly, and they want to upload work to the server for safekeeping.

Each user can have as many shelvesets as desired. Other users are able to see what shelvesets are available, but they can't access them unless permission is explicitly granted.

Work Item Integration

From a management standpoint, one of the premier features is the ability to associate a work item with check-ins. This capability will enable others to see why code was changed. Ideally, they'll always see a code change linked back to a requirement or bug. This type of managerial oversight is important in any project in which developers shouldn't be able to add features or make unnecessary changes.

Check-In Policies

Even though a project manager or team lead might tell their developers, "You can't check in your code until you perform a clean build" or "Don't even think of uploading code that fails its unit tests," these words can be sometimes be ignored. With VSTS, policies can be created and enabled inside Visual Studio that will enforce the two conditions just cited, as well as others. Figure 2-8 shows the various check-in policy types.

Figure 2-8

VSTS check-in policies

Clean Build

The project must compile without errors before check-in.

Static Analysis

A static analysis test must be run before check-in.

Testing Policy

Check-in tests, such as unit tests, must be run before check-in.

Work Items

One or more work item must be associated with the check-in.

Build and Release Management

The term build refers to the compilation of all the files, libraries, or components into a new set of executables, libraries, or components. VSTS's build management provides an easy, end-to-end solution to produce daily builds, with complete testing and automation. It will pull all the related project files out of Team Foundation Source Control.

Pressing F5 or using the Build menu option inside Visual Studio 2005 works great for smaller applications, where they have local access to all the source-code files and don't have any additional requirements. Larger projects tend to have many other tasks bundled with the actual compile process. Build automation allows for the following additional prebuild and postbuild requirements:

Check out source-code files for the build.

Run static analysis, unit tests, or both.

Compile sources.

Save code churn, test, code coverage, and other build information.

Drop the binaries into a predefined location.

Generate the reports.

The VSTS build automation tool provides an out-of-the-box solution to meet these requirements. Its wizard helps to create an automated build script so that organizations can automate these tasks. The reports can then be studied to determine the general health of the project and the velocity of the development effort.