Visual Studio 2008 provides an integrated development environment for applications ranging in size from small to very large, distributed, load-sharing environments. While Visual Studio 2008 provides the editors, debuggers, compilers, and test routines required to cover the software development lifecycle, there is one component missing from Visual Studio that is an integral part of most development efforts: source control.

Source control, also called revision control and source code management, has two primary goals: providing a repository for code in one location for ease of access and backup, and to provide the ability to "undo" changes made and restore an earlier version of the code. In its simplest model, a source code control system is a virtual library that lets users check code files in, and can check out code files when development or changes are needed. All changes to source code is done when the code is checked out, and after checking in a difference (called the "delta") is calculated. By forcing the check-in paradigm, two developers cannot make changes to the same code at the same time, preventing problems.

Traditionally, stand-alone source code control systems have been used, dating back to packages such as the Source Code Control System (CSSC), RCS (Revision Control System) and CVS (Concurrent Versions System), all of which were in wide use in UNIX development environments before the Windows platform was developed. For Windows, a number of versioning and source code control systems emerged, most of which tended to be decoupled from any development tools. Working with these systems, a source code file would be checked out, then opened with a development tool, then saved and checked in, all as separate tasks. Later, version control was integrated into some development tools, although Microsoft's development suite has always been the exception.

Microsoft's Visual SourceSafe was the first real source code control system backed by Microsoft, and while it wasn't tightly integrated with its development tools, it did provide some ties. As Visual Studio replaced the stand-alone compiler products, a new product, called Team Foundation Server, designed for use by larger development teams, has become an integral part of the latest version of Visual Studio. Still, both products are external to Visual Studio, although integration has been improved.

Visual SourceSafe

Microsoft's Visual SourceSafe (VSS) is intended for use for smaller development projects, although it has been employed in larger projects. VSS started as a product Microsoft bought from another company, modified and introduced in 1994 as SourceSafe 3.1. The original versions of VSS were not designed to support multiple developer environments in a client-server model, but were local library systems designed to allow one developer to manage their own code as well as create and manage multiple configuration streams for a product. Support for the client-server model was not properly introduced until the Visual SourceSafe 2005 release.

VSS is designed to be a relatively light-weight source code management system, and it has an interface that is easy to use, but it is not robust and capable enough for larger development environments. For smaller teams (up to ten users, for example), VSS is capable of handling the source code control tasks, as long as multiple streams are not required. Also, there are some corruption issues with VSS that arise when a crash occurs and the database is not properly closed, which can render the entire archive unusable (there are workarounds, of course).

Visual SourceSafe 2005 is still the current release, and it was included as part of the Visual Studio 2005 Team System or could be purchased separately. Microsoft continues to support VSS, but has moved its focus to Team Foundation Server which addresses most of VSS' problems and supports large development efforts.

Team Foundation Server

Team Foundation Server (TFS) was developed by Microsoft as a more versatile source code management system designed for larger application development teams, as well as to provide better integration with Visual Studio. Based on a SQL Server 2005 database for a repository, TFS performs several tasks in addition to source code management: it also includes a project tracking system, and a data collection and reporting facility. Intended to be used as part of Visual Studio Team System or as a standalone product for other development environments, TFS has been designed to provide a solid environment for project tracking and development. TFS does not have a user interface of its own, but rather uses a set of web services that allow other software to communicate with TFS. Visual Studio Team System, for example, can integrate with TFS and the VSTS IDE is used to manage many TFS tasks.

TFS is usually installed on one server, with everyone in the development project accessing the server through a network. However, individual developers can run TFS or a subset, such as the Document Explorer, locally. The Document Explorer lets users see the repository and work with the files in it, but the actual repository is located on another machine.

The unit of organization for TFS is the project, which can consist of one of more Visual Studio projects, a SharePoint repository for documents and team information, configuration files for various VSTS activities, and a set of user-created work items. Projects can be set up using a template (there are several provided with TFS) but once a template has been assigned to a project, it cannot be changed. Unlike traditional source code systems, TFS changes the focus from code-centric to project-oriented tasks. Almost all activity with TFS is based on a work item, which is a single unit of work to be completed (whether code or otherwise). A work item from the developer's point of view may be creating code, architecture and design documents, or bug fix requests. A work item from a project manager's point of view may be focused more on the project management tasks leading to gates and milestones. There are other views, as well, such as creating documentation as a work item, producing use cases or tests, creating a marketing presentation, and so on.


For most developers, the main advantage of TFS is the source control system which is more formally called Team Foundation Version Control (TFVC). TFVC is built on a SQL Server 2005 database and allows code to be checked in and out through the VSTS interface. TFVC supports multiple checkouts, allowing several developers to work on the same code, and can manage conflict resolution between check-ins when this happens. TFVC also supports a useful concept called shelving, wherein new code changes can be retained but not committing them to the source code yet even though they are available to other developers. TFVC allows security levels to be set for different levels in a source code tree, restricting access and rights to chunks of code.

TFVC integrates a SharePoint Services infrastructure, so it is useful for more than simply source code. Larger development projects will use TFS for source code, documentation, marketing and sales content, presentations, and all other generated files related to a project. All these items are then versioned automatically by TFVC.

In use, TFVC works well with Visual Studio Team System. When a developers wants to work on code maintained in TFVC the code can be checked out through the VSTS interface, with the connection to TFS transparent to the user unless intervention is required. Visually, Visual Studio Team System shows the status of code files in TFS using icons. Check-in policies can be put in place, forcing a developer to run a code analysis task on the modified code prior to checking in, for example, which reduces the number of errors in the library. Although developers still work with the work unit model, it becomes almost transparent after a few hours of use, and the ability to check code in against more than one work items is useful. This particularly pays off for the developer when dealing with work items related to bugs or feature requests, where several work units can be closed (or at least moved towards closure) with a few minor changes in code. The check-in policy can be set to force the developer to update the status of the work item when code is sent to TFVC. This is useful when changing the status of a bug to "fixed" is often forgotten by the developer.

Branching of code is fully supported by TFVC. Branching creates a diversion of one project stream into two or more project streams, and can occur at the highest level, or at any level below including at the individual file level (so Windows XP files can be separated from Windows Vista files, for example, as part of a larger project). Branches can be merged together, as well, with automatic detection of code conflicts between the merged streams. In most cases, merges can be performed with automatic resolution of conflict code, but some code may be flagged for manual intervention.

One oft-underappreciated aspect of TFS is the ability to perform team builds. This is done through a build server that is integrated into TFS and can be run from any machine that runs Visual Studio Team System. Team Build allows a developer to create an immediate build of the latest code (for testing and validation after a code change, for example), and scheduled team builds can be performed at preset intervals. A recording stream is maintained for all builds, failed and successful, and can be integrated with the project plan to reflect progress.

The project tracking aspect of TFS is of benefit to project managers, and it can be integrated with Microsoft Project (and external third-party project management software using the interface specifications). In addition, Microsoft Excel can be used both for imports and exports of information. The project manager's view of a development project allows for the creation of teams, overall project milestones, and several levels of detail down to the work item level. Using predefined templates, project management information can be published on a site and be constantly updated providing the project team with a current view of the project and its progress. TFS allows comments to be recorded on various aspects of the project, retained and managed by the versioning system, and readily viewable as a living, evolving document.


Other than the project tracking aspect, the reporting package in TFS is valuable. Reports can be generated on just about any aspect of a project, from high level views down several levels of detail to individual work items, and can be in a wide variety of formats (such as PDF, Excel files, graphic files, etc). Because of the integration between TFS and Visual Studio Team System, build results and test case results can be recorded and generated as results related to the project, too. There are a wide variety of predefined reports in TFS, and new reports can be created and saved or conducted ad-hoc using the SQL Server Reporting Services. All these reports are available both through the TFS-created SharePoint portal, as well as through Visual Studio Team System for development users.

TFS was initially introduced with the Visual Studio 2005 platform, but the latest release includes a number of new features. TFS 2008 integrates with MOSS (Microsoft SharePoint Server 2007), which allows TFS content to be integrated with MOSS-managed project sites. The performance and security of TFS also has been improved, and general improvements across all features realized (as you would expect from a major new release). Indeed, performance has improved considerably, especially with the SP1 update to TFS, with some tasks taking a small fraction of the time the older system required.

Support for current Microsoft products has also been added, naturally, so SQL Server 2008 and Windows Server 2008 are supported completely. Of note with the latest version of TFS, at least from the development team aspect, is the ability schedule builds using the Team Build subsystem and the ability to provide continuous integration as changes are made in the code base, triggering a new build with each check-in. (Continuous integration is especially useful for smaller projects or subprojects, and for use in an agile development environment.) TFS 2008 also allows Web-based access for many aspects of project management, work item tracking, and version controls, allowing remote work to be performed more easily than the previous release. The SP1 update for TFS adds even more useful features, such as drag-and-drop for file management (so you can drag files from Windows Explorer into the TFVC window, and vice versa). The work item interface has also been improved with support for the Office 2007 "ribbon" interface. Finally, a Visual SourceSafe migration tool has been introduced to make it easier to move projects and content from VSS to TFS with heavy validation and automation to prevent common import errors.

One of the strengths of Team Foundation Server is its extensibility which allows many useful actions for developers and managers. For example, using an included utility called BisSubscribe, a user can have Team Foundation Server notify them when a change to source code is made, a new event is posted, or many other conditions that trigger a notification. For these subscriptions to event notifications to work, a Web part has to be linked in that catches the events themselves. Part of the Web part code allows users to specify the types of events to be subscribed to, as well as the attributes or signatures of the Web service method that trigger an event notification. This allows extensive modification, providing the ability to add a new capability to Team Foundation Server and then use the included notification process to catch triggers from that new capability.

A set of add-ins from Microsoft and third-parties takes advantage of Team Foundation Server extensibility. For example, Microsoft released a Model Designer Power Tool that is designed to allow system designers and architects generate models of an application, especially focused on lowering TCO (Total Cost of Ownership). As part of the TCO focus, there are models for creating instrumentation for operations, as well as other aspects of application management.

Team Foundation Server is obviously based around the management of team projects. Team projects are simple to create, requiring the manager to follow a set of dialogs that define most aspects of the project (parts can be skipped during project creation and completed later, or details provided as part of the initial setup). After assigning a project name for the new team project, a process template can be assigned that works with the development methodology to be used, including standard Microsoft Solutions Framework (MSF), a template for agile development, or a template for a CMMI process improvement project (which also works with other quality approaches such as Six Sigma).

While Team Foundation Server is typically used with the usual full software development life cycle (SDLC) it can be quite readily adapted to agile methodologies. Agile provides a continuous integration approach to software development, and is intended to small (2-5 people) autonomous teams with an emphasis on rapid change and not on formal documentation or process. Under agile, functional specifications evolved at any stage in the process, instead of being rigidly defined up-front.

Since developers in an agile environment will still be using Visual Studio 2008, Team Foundation Server becomes an integral part of the development environment for agile, too. Since Team Foundation Server is the engine that drives a lot of the Visual Studio Team System functionality, TFS has to be adaptable to suit agile development. The aspect of Team Foundation Server that is especially suited for agile development is the source code control system built into Team Foundation Server. As code revisions are made, they are fully tracked by TFS and allow roll-backs to occur without effort if a set of code modifications (or even an entire development thread) turns out not to be desirable. In this case, Team Foundation Server works well for agile development.

Another aspect of agile development is creating frequent stand-alone builds, especially at the gates (which usually are 4-6 weeks apart). The Build Server that is part of Team Foundation Server helps in this regard, allowing incremental builds to occur at any interval, especially daily, as well as managing the goal of creating a functional application at each agile gate.

For SDLC or agile development, unit testing is a key component of development efforts, and Team Foundation Server can be used to manage an entire project's unit test suite. While each component in an application will have its own unit tests, running all unit tests for a project can be a difficult task. By using Visual Studio Team System to create a set of unit tests for the overall project classes and methods, results of the complete project unit tests can be handled, managed, and reported by Team Foundation Server.

As mentioned earlier team projects can be created in Team Foundation Server that support CMMI Process Improvement projects. The MSF for CMMI template and associated files are designed to specifically comply with the SEI (Software Engineering Institute) CMMI (Capability Maturity Model Integration) standards. These templates also create required tracking databases in SQL Server.

For team managers, the reporting features of Team Foundation Server will help with roll-up reports for higher levels of management, as well as for team members. The ability of Team Foundation Server to export reports to Excel makes it easier to include up-to-date report data in presentations and graphs, for example. Team Foundation Server can also export work information such as work items, work assignments, outstanding items, and so on to Excel for easier summary and distribution. Team Foundation Server can also import information from Excel, so a team member can edit information in Excel and then publish the information to TFS. Keeping both the Team Foundation Server database and Excel spreadsheets allows for current information to be maintained in both formats. For status meetings, the Excel integration allows fast retrieval of information. For example, it takes only a few minutes to export a list of all outstanding bugs and their priorities from Team Foundation Server to Excel, and then wrap that list into an informative graph and table. Updating the Excel spreadsheet at any point allows the data to always be fresh, and can exported and published to a Web site at preset intervals. In addition to integration with Excel, Team Foundation Server integrates with the SQL Reporting Services to provide more complete details of a project's progress, as well as more integrated reporting from multiple sources. Team Foundation Server can also integrate with Project Server.


Microsoft's two source code systems, Visual SourceSafe and Team Foundation Server, are intended for very different project types and sizes. For a small team of developers who only need version tracking and a single-location repository, Visual SourceSafe will perform all the tasks required. However, once the development project moves above a simple project, involving multiple team members and a need to better manage the overall project, TFS comes into its own. The strengths of TFS are remarkable, and its clean integration with Visual Studio Team System allows it to be used by developers with very little ramp up. For the project manager, TFS presents a new and useful way to track projects from start to finish, with updates maintained in real-time as work is performed and managed by the repository.