Visual Studio 2005 Team System: Enterprise-Class Source Control and Work Item Tracking

  • Article

 

Barbara Denz and Korby Parnell
Microsoft Corporation

May 2004

Applies to:

**   Microsoft** Visual Studio® 2005 Team System

Summary: This article describes the integrated change management components for enterprise-class source code control, work item management, and reporting available in Visual Studio 2005 Team System. (10 printed pages)

Note This document was developed prior to the product's release to manufacturing, and as such, you may find inconsistencies with the details included here and those found in the shipping product. The information is based on the product at the time this document was created and should be used for planning purposes only. Information is subject to change at any time without prior notice. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Contents

Introduction
A Brief Discussion of Software Configuration Management (SCM)
SCM Tools
Traditional Approaches to SCM
Microsoft's Approach to SCM
Integrated Work Item Tracking and Source Code Control
Checkin Policies
Generating Reports
Work Item Tracking Features
Tracking Work Items Using a Web Interface
Source Code Control
Source Control Provider Description
Conclusion

Introduction

Do you work on a team that develops enterprise-class applications? Do you deploy your applications into a Microsoft .NET environment? If so, you know that the complexities of designing, developing, delivering, and maintaining these applications require you to track requirements throughout your product development lifecycle. Visual Studio 2005 Team System is a software development life cycle (SDLC) tool that addresses these requirements. For more information about Team System, see Visual Studio 2005 Team System: Overview.

Visual Studio 2005 Team System is a complete set of software development tools for software architects, developers, testers, and other team members such as project managers, support staff, and documentation writers.

A Brief Discussion of Software Configuration Management (SCM)

Software configuration management (SCM) plays an important role in the software development life cycle (SDLC). SCM is the set of practices, policies, and processes that your organization uses to:

  • Control access to source files
  • Create and manage work items
  • Generate product builds
  • Manage product releases

An effective SCM strategy is like a good shoe—it conforms to the unique needs of your project and team over time; cannot be easily shared with other organizations; and once in place, is easily forgotten until you have to work without it.

An effective SCM strategy enables your team to work on multiple versions of a product simultaneously, port changes from one release to another, work in the same files at the same time without losing data, and trace code defects back to their origin and creator with little effort.

The SCM tools that facilitate these change management tasks fall into three categories:

  • Source code control
  • Work item tracking
  • Auditing and reporting

SCM Tools

Software tool vendors provide a daunting array of tools that you can use to implement a change-management strategy for your team. These tools can be divided into three types: standalone SCM applications, integrated change management toolkit, and SDLC tool suites.

Standalone SCM applications do not talk to other SCM applications. For that reason, it can be difficult for development team members to associate the configuration items, which include source files, work items, builds, projects, and so forth, assigned to them with other types of configuration items. The most common manifestation of this issue is that developers cannot associate a work item with a source file or changeset.

Alternatively, an integrated change management toolkit enables team members to associate work items with source-controlled files. Some tools, like Visual Studio Team Foundation, enable developers to perform essential change management tasks inside an integrated development environment (IDE), while also providing a standalone interface for team members who work externally or need to perform more extensive change management tasks.

Finally, an SDLC tool suite enables team members to associate work items with source-controlled files. SDLC tool suites represent a comprehensive approach to software configuration management and often impose SCM discipline on all aspects of the development life cycle. They often include specialized tools and features for each functional area of a software development team, from architecture to development to documentation, as well as tools such as work item tracking and source code control applications for vital change management tasks.

Traditional Approaches to SCM

Traditionally, teams have been forced to choose between two approaches to SDLC and software configuration management: ad hoc and command and control.

The Ad Hoc Approach

Teams that adopt an ad hoc approach to SCM usually do so incrementally, learning by trial and error, and filling holes in their SCM strategies as they go. They often employ a mix of standalone tools and development environment plug-ins such as Visual SourceSafe, which provides integrated source control services in the Visual Studio development environment.

Advantages of Ad Hoc SCM

  • Low initial cost.
  • Flexibility: Contributors don't feel too constrained by the process or tools because both can be adjusted to their preferences and requirements.

Disadvantages of Ad Hoc SCM

  • High total cost of ownership (TCO): Tools and procedures must be continuously refined, improved, or replaced. It takes a long time for new employees to master the tool or process.
  • Communication breakdowns: The SCM process disrupts workflow. Developers might not communicate changes that could break builds or test cases to testers until it's too late, because their SCM tools don't allow or encourage them to do so at the time when a change is made.
  • Lack of predictability: Due to a lack of accurate reporting functionality, project managers find it difficult to ascertain the exact state of a release at any one point in time.
  • Slips and service packs: Developers find it difficult to adequately communicate potentially breaking changes to testers until it's too late because their SCM tools do not allow or encourage them to do so at the time when the change is made. This lack of cross-functional communication leads to late-breaking changes that force release delays (slips) or in some cases, compel a team to ship on schedule and later create a Service Pack for defects (bugs) that they might have been able to fix more easily before the release.
  • Lack of reproducibility: The lack of both reporting functionality and integration between defect tracking and source control systems makes it difficult to track a bug back to its source.

The Command and Control Approach

End-to-end, SDLC solutions for software configuration management help—and in some cases compel—project contributors to perform development tasks in accordance with SCM prescriptions or team-specific rules. End-to-end life cycle management tools can be used within the development environment or as standalone applications. Most importantly, SDLC solutions improve the communication between contributors by enabling them to more easily associate the configuration items assigned to them with other configuration items. Traditionally, such solutions have been costly, meaning that they are usually implemented by enterprise development teams and ISVs.

Advantages of Command and Control SCM

  • Good cross-functional communication: For example, project contributors subscribe to and receive email notifications informing them of important changes. This allows them to work in tandem and complete cooperative projects more efficiently.
  • Predictability: With robust reporting, auditing, event notifications, and integrated change management tools, project managers can ascertain the exact state of a release at any point in time. Consequently, release dates are easier to predict and post-release service packs are less frequently needed.
  • Reproducibility: Integration between work item tracking and source control systems makes it easy to track a bug back to its source. In turn, teams can more confidently work on two or more versions of a product in parallel, knowing that differences between versions can be readily identified and reconciled when they occur.

Disadvantages of Command and Control SCM

Command and control SCM solutions are often resisted by individual contributors.

  • Complexity and Cost: Learning time for new employees is long. SDLC toolkits are expensive to set up and maintain. Implementing an integrated SCM system can take up to a year and require that teams hire special SCM consultants to keep the system running smoothly.
  • Rigidity: Unlike ad hoc solutions, SDLC toolkits are often difficult to tailor to the specific needs of a team. When doing so is possible, it can be so complex or require such detailed knowledge of the SCM software that teams have to hire an SCM specialist to do the job.

Microsoft's Approach to SCM

Visual Studio 2005 Team System is a flexible, end-to-end software development lifecycle (SDLC) tool suite that combines the productivity and innovative potential of Visual Studio with the predictability and reproducibility of a process-oriented solution for software life cycle management. Team System incorporates tools for architects, developers, testers, project managers, documentation writers and other project contributors.

At the heart of Team System are integrated change management components that unobtrusively inject SCM process and team-specific requirements into the developer's daily workflow. These components are:

  • Work item tracking
  • Source code control
  • Policy support
  • Notifications and report generating capabilities
  • Collectively, these components are known as Visual Studio Team Foundation.

Integrated Work Item Tracking and Source Code Control

Visual Studio Team Foundation knocks down the wall between source control, work item tracking, build management by enabling project contributors to associate work items with other types of configuration items, or artifacts.

There are four types of artifacts in Visual Studio Team Foundation: work items, source files, changesets, which are the products of a check in operation, and builds. A work item can contain links to the other three artifact types.

Linking Source Files to Work Items

When you modify a work item such as a bug, you might want to associate it with the source-controlled file with the work item. If the code you are working on and checking in corrects a problem in a bug, you would want to tie a work item to a source file. This links the bug to its correcting code for anyone to see. For any other work item types, code might interact with it in different ways. In all cases, tying them together saves time and energy for your team.

Linking Work Items to Changesets

When you check revisions to multiple files into source control, a new changeset artifact is created with a unique identifier in the source control repository to contain the revisions and related metadata. Any work items that you selected for association with the changeset during the checkin process are then modified to point back to the new changeset. Thus, the work item is linked to the changeset.

Linking Builds to Work Items

When you discover a code defect in a build or work items become available in a build, there is an inherent relationship between the work item and the build. Visual Studio Team Foundation manifests this relationship as a link that is stored in the work item.

Checkin Policies

Using Visual Studio Team Foundation, a portfolio project administrator can associate custom or boilerplate policies with checkins and other events. A policy is a guideline that either provides operational context or that strongly suggests that certain conditions be met before performing an SCM operation.

The most common type of policy is a checkin policy. A checkin policy validates that a developer's changes comply with organizational requirements before checking in a set of pending changes to the repository. When a developer attempts to check in pending changes that are in breach of team policy, a policy warning is raised.

Note A project contributor can ignore policy warnings. However, a project administrator can request notification via e-mail when a policy warning is ignored.

You can think of policy warnings as an extension of build errors in Visual Studio. Policy warnings are team-specific source control integration guidelines that remind developers to perform certain actions prior to checking in their pending changes. A policy is a reminder, not a directive.

Generating Reports

Using Visual Studio Team Foundation, you can generate reports on the progress of an individual work item, track it to completion, and even view the code associated with its resolution. Developers can associate a code checkin with the work item and builds that necessitated it. If the work item is generated from a failed test result, Team Foundation features enable you to see what went wrong during testing, drill down to the code that fixed it, and verify that the fix resulted in a successful test pass. You will no longer need to remember or write down numbers of bugs and code checkin dates to see what fix finally fixed a bug—it will all be in one place.

Work Item Tracking Features

Work items are units of work assigned to members of your product team. The work items can be modified and reassigned by anyone with appropriate permissions. They are tracked in reports, scheduled using Microsoft Project, and lists of them can be exported to Excel for more analysis. Teams can define their own work item types with their own fields, a form, state-transitions and rules. Developers use work items to prioritize their work, make notes about dependencies, and to notify testers and other teammates when a fix is in place or requires additional action. Architects, designers, testers, technical writers, localizers, and usability engineers can create and assign work items to record issues with a project configuration item and track progress toward the completion of their goals. Examples of the common work item types that ship with Team Foundation Server include: Bug, Requirement, Task, Risk, and Schedule.

Creating Work Item Queries

There are so many places to begin when you track an issue, but the most likely is to create work item queries that give you the work items you want to work with. From the work item query builder, you can create queries that include or exclude work items for any field in the database, and for all the possible values for that field. You can also search for any bugs that have been assigned to your project. Then, if you are part of a security group set up by the Project Administrator, you can assign bugs to the developers who need to fix them. You can search for any work items assigned to you. You can search for work items that have changed status, such as those that are now resolved or those that have recently been closed. And when you are done with that, you can refresh your query and see how what you have done has changed the results list—all with a click of a button.

Processing Bugs from Detection through Resolution and Testing

Every project contributor needs to know how to process bugs from detection through resolution and testing. Depending on how your team guidelines are created, potentially everyone on the team can find and enter bugs into the team's Portfolio Project. Typically, the person who creates the bug is responsible for verifying that the bug does not already exist in the project. Depending upon the configuration and requirements of your team, your Project Administrator might set up a special group to prioritize incoming bugs that are not assigned to a particular person. This team is responsible for assigning bugs to the most appropriate person for further action, resolving bugs as "by design," or determining that an item does not meet the "bug bar" or milestone guidelines.

If the bug is assigned on to a developer to fix, the developer can fix it according to the steps provided, ask for clarification on steps to reproduce the bug, work with the tester to identify underlying causes, locate duplicate bugs that are being fixed by other team members, locate and link to dependent bugs, and more. When the developer finishes work, the bug is assigned on to a tester to test the fix and either accept that it is fixed or regress the bug for additional work. And, according to your team's guidelines, the bug is closed by the person or team group responsible for doing so.

Tailoring Work Item Forms to Your Team Needs

As a portfolio project administrator, you can either accept the form that Visual Studio Team Foundation includes for you or you can customize the form to meet your team's needs. For example, you can customize the field name your team members see and the placement of all fields on the work item form.

Setting Rules and Permissions for Your Forms

Not only can you define who can see your hierarchy, you can also define and customize your own forms by using the work item types that come with the toolkit. If you choose not to use the work item types that come with the toolkit, you can create, import, export, and update work item types. For added security, it is also possible to control individual team members' views of your hierarchy and assign project and hierarchy permissions accordingly. As a final step, you can release the form for users to complete.

Administering Server Operations

As an operational administrator, you manage all the server-side interactions with users and data. You can monitor the server and manage alerts, back up and restore project databases, plan server capacity, manage server patches to stay on top of security alerts from Microsoft, set up and upgrade server-based rollouts, check database consistency and repair problems, diagnose performance problems, and assign server-side and database permissions.

Tracking Work Items Using a Web Interface

And, finally, without installing all of Visual Studio, you can track work items using a Web interface shell of the work item tracking toolset. You can still monitor and maintain work item tracking information but without the entire server-side information or Visual Studio product installed.

Source Code Control

One of the easiest things you can do to ensure successful collaboration on your software development projects is to place your team's shared development resources under source control. Source control protects team resources from accidental deletion, protects individual changes from being blindly or unknowingly overwritten, enables multiple developers to work on the same project items or branches of a project concurrently, and maintains a version-by-version history of all project items.

Note For individual developers or small teams who need a lightweight solution for source code control, Microsoft will continue to enhance and support Visual SourceSafe. We will ship Visual SourceSafe 2005, which will include enhancements such as remote Web access over HTTP, a LAN performance booster, Unicode and XML support, and regional time zones and language support. For more information, see Visual SourceSafe Roadmap.

Visual Studio Team Foundation includes an enterprise-class source control provider that picks up where Visual SourceSafe leaves off. It is reliable, scalable, fast, more securable, extensible, and includes almost all of the easy to use Visual SourceSafe features with which you and your team are already familiar.

The Visual Studio Team Foundation source control provider ships as a standalone SCM application or as an integrated change management component in Visual Studio 2005 Team System. Inside Visual Studio, the Team Foundation source control plug-in reduces the complexity of source control by making it an extension of project file management. Developers can perform all source control operations without ever leaving the integrated development environment (IDE) or opening another application.

Inside or outside Visual Studio, the Team Foundation source control provider seamlessly integrates with other Team System components such as work item tracking and reporting.

Source Control Provider Description

Implemented as an ASP.NET Web service, the Visual Studio Team Foundation source control provider enables you to access and manage your source-controlled configuration items from anywhere on the Internet.

Source files and project metadata are stored in a Microsoft SQL Server database. Source control operations are performed in an atomic and transactional way. This architecture has the following advantages:

  • Scalability: Given sufficient hardware, your source control repository can contain over a terabyte of data. Team Foundation supports between five and 500 users.
  • Integrity and Reliability: The types of data integrity issues associated with file-based source control applications are practically eliminated.
  • Speed: Depending on the operation requested, Team Foundation is orders of magnitude faster than Visual SourceSafe.

Developing in Teams: Isolation and Integration

One of the primary goals of any software configuration management (SCM) methodology or application is to support parallel development.

Parallel development, which is the process of coding, testing, and building multiple releases of a software application component concurrently, liberates individuals from the constraints of serial development, where one developer completes one task before the next can begin another. Parallel development allows multiple individuals to work in isolation, safely developing the same or different parts and versions of a component at the same time as other developers. To realize the benefits of parallel development, teams must implement processes and use tools that enable project contributors to expeditiously, incrementally, and sometimes automatically resolve small conflicts before they grow into big ones.

Visual Studio Team Foundation enables parallel development by allowing developers to work in isolation (as if on a one-person project) and integrate on demand, smoothly merging the pending changes in a developer's private workspace with the repository version during Get and Checkin operations. When conflicting modifications occur, a developer can merge changes between two branches using a robust, built-in merge engine. Optionally, you can plug in a third-party merge utility.

If you want to temporarily preclude changes to an important project, you can lock items in the repository.

Enterprise source code control provides an archiving command called Shelve that makes it easy to create and switch over to a personal copy, or branch of a project to develop a hot fix for a product release or to simply experiment with an alternative development method on a scratch copy of your changeset.

Source Control Integration in Visual Studio

In Visual Studio, you can silently and automatically add all new solutions and projects to your source control repository in Visual Studio 2005 Team System by selecting the Add to Source Control Automatically option in the New Project dialog box. By default, all source-controlled items are checked out silently whenever you edit them.

Unlike many past source control plug-ins for Visual Studio, when you rename, move, or delete a source-controlled item, you do not have to worry that your change will not be properly shared with your teammates. The change is isolated in your local workspace as a pending change until you check it in. When you do so, the change is propagated to other users' workspaces the next time they perform a Get or Check In operation.

Other Visual Studio Team Foundation Change Management Features

  • One-click Build
  • File-level user permissions
  • Granular auditing capability

Extensibility Story

For the complete extensibility story, see Visual Studio 2005 Team System: Extending the Suite.

The managed API, sometimes referred to as a client-side API is the primary and preferred interface for customer and partner extensibility. This API lives on the client for the Visual Studio and TFC user interface. It is a .NET managed interface and therefore is accessible from any Visual Studio language. An overview of this API is covered later in the Architecture section of this paper. Integration and extensibility are the primary reasons behind the work item tracking tool.

It is not correct to think of this API as being only client-side. The same API used by the Visual Studio Integrated Platform (VSIP) user interfaces will be used on the Web server for the work item tracking Web application.

Conclusion

Visual Studio Team Foundation provides integrated source control, work item tracking, reporting, and custom policies that enable your team to efficiently manage change in your software development projects.

For more information about the other members of the Visual Studio Team Foundation, see: