Team Foundation Server: At Work

Version control, work item tracking, project management, and build management

Brian White
Microsoft Corporation

October 2005

Applies to:
   Microsoft Team Foundation Server
   Microsoft Visual Studio Team System

Summary: This article looks at the features of Team Foundation Server, a component of the Visual Studio Team System. (9 printed pages)

Note   This content originally appeared in the January 2005 edition of .NET Developer's Journal. It is reproduced here with permission of the publisher.

Contents

Introduction
Team Projects
Version Control and Work Item Tracking
Build Management and Testing
Project Management
Project Reporting and Metrics
Conclusion

Introduction

Do you find yourself tired after sitting in meetings all day? Do you have feelings of uselessness after weeks of bug fixing? Do you often find yourself feeling lonely, as if you've lost touch with your team and the status of your project? Are you frustrated by frequent fire drills and the sense that your project is in utter chaos? Are you hopelessly lost in a sea of changing policies and procedures with no end in sight?

If you answered yes to any of these questions, you may be clinically depressed and require extensive psychological counseling. Or maybe, just maybe, you are using the wrong software life-cycle tools.

As part of the Visual Studio Team System 2005 release, Microsoft will introduce a new server product designed specifically to improve software team collaboration and increase individual productivity. This new product is called Team Foundation Server (TFS). This article discusses the key objects created and managed by software teams, why the integration between these objects is so important, and how Team Foundation Server can help your team be more successful.

Team Projects

Software development is a team activity now more than ever. When you think about software teams, what are the key objects that come to mind? First and foremost is the simple notion of a project. Not project in the Visual Studio solution sense of the word, but rather a set of individuals with shared goals to be achieved in a desired time. Team Foundation Server calls this a team project. In life-cycle tools today, this is mainly just a concept and not a physical object at all. You'll find tools either have no notion of this fundamental concept, or they have several different notions that are not consistent.

To deliver tight integrations, a software life-cycle tool suite must have a common, shared notion of a team project. Also, an actual object is needed that is managed with persistent data, so that automation, relationships, and communication are possible. Team projects are central to everything Team Foundation Server provides. Team projects are surfaced in several places, primarily inside Visual Studio in the Team Explorer and through the Team Project Web site (based on Windows Sharepoint Services). Figure 1 shows the team explorer inside Visual Studio, with the team project Web site opened as a document window.

Figure 1. Team Explorer

Every team follows different processes and procedures. You may want your Web site to look a certain way, you may have specific guidance for how development gets done, you may have your own templates for documents, and you may want to organize your documents using a specific hierarchy. If your team is larger, you may also have special roles for team members and specific permissions assigned to these roles.

Team Foundation Server provides a completely customizable way to define all of the data surrounding a team project and encapsulate this information into a methodology template. When a new team project is created, Team Foundation Server uses the methodology information to automatically configure the team project, including creating the team project Web site. Methodologies can be exported, customized, shared, loaded, and even bought and sold by third parties.

With Team Foundation Server, you can create new team projects quickly without having to do hours or days of setup work in various tools using various techniques.

To help get you started, Microsoft will provide two methodologies for use with Team Foundation Server: MSF Agile and MSF Formal. MSF Agile draws on the best practices of the Agile community and the Microsoft Solutions Framework to deliver a lightweight, easy-to-use methodology geared toward small teams who must move quickly. MSF Formal is targeting larger teams who require more control over their development processes. MSF Formal is designed to help teams achieve CMMI Level 3 maturity.

Version Control and Work Item Tracking

At the heart of software development is the edit/compile/unit test/debug cycle. Surrounding this is usually a team build (often nightly), integration and system testing, and bug submission and resolution. The key objects being created and managed here are source code, work items, builds, and tests. You'll see the relationship between these objects offers significant integration and automation opportunities that Team Foundation exploits.

Source code is another obvious object that must be tracked and managed for software teams. Software configuration management/version control tools are widely seen as a necessary part of any reasonably sized software team. Team Foundation Server includes a new version control solution that supports many advanced SCM features such as namespace versioning, automatic check in, and changes sets. Team Foundation Server also includes some new and innovative SCM features such as putting work on hold, sharing a change with another developer before check-in, and integrated check-in policies (see Figure 2).

Figure 2. Pending Check-ins

Note   Team Foundation Server's Version Control will not replace Microsoft's Visual Source Safe (VSS). VSS will continue to be developed and supported for smaller teams (< 5 people) requiring only version control capabilities. Team Foundation Server's Version Control is targeted at teams of five or more that require more advanced version control features and integrations with other life-cycle tools.

Work items is another major object that teams use to prioritize and track and work. Work comes in many forms: bugs, tasks, features, requirements, change requests, issues, and so forth. Most teams today need to deal with several different tools to make sure they are getting a clear picture of everything that needs to be done. Team Foundation Server has the flexibility to manage all of these types of objects as different work item types, but tracks them in one place, allowing for cross work item type reporting and queries. All work items include things such as a description, assigned user, and states for tracking progress. However, with Team Foundation Server, work item types are completely customizable, which allows your team to define the fields, rules, state model, and form layout that make sense for your team.

The real power of Team Foundation Server comes not from separately managing the source code and work items, but rather from their integration and the automation that can be done with this relationship. By simply enabling a check-in policy, software teams can make it required that developers specify one or more work items whenever they perform a check-in. This is easy to do by having work items readily available in an integrated Pending Check Ins window (see Figure 2).

Checking the box next to the appropriate work item links the "why" of a change to the "what." The benefits to productivity and the automation possibilities of this simple link have yet to be fully realized in tools today.

One example of the automation benefits is the support of automated state transitions on work items. In the past, developers would check in their code, and then go to their bug tracking tool to transition one or more bugs into the next state ("Ready for Test" or "Resolved," for example). With Team Foundation, a developer can simply indicate in the pending check-in dialog box which "check-in action" they want to occur after the check-in has finished. If they select the "resolve" action, the work items will be automatically transitioned to the next state. This reduces work for the developer, increases the flow of changes through the life cycle, and makes for a cleaner hand-off between the developer and tester. Testers who receive this work item to verify can easily access and review the source code changes by following the link recorded in the work item.

Build Management and Testing

Another object that is central to a software development team is the "build." Similar to the concept of project, builds are often treated as second-class citizens in life-cycle tools, and most companies are left to develop their own in-house build systems. A build is simply an object that identifies the manufactured software product. The source code and build scripts are the raw materials; the manufacturing process begins when a build is started; and the resulting libraries, executables, and other supporting files are the result.

The whole build process does not really stop there because after the freshly constructed product drops off the assembly line, it must go through testing to ascertain its quality. Typically, a set of smoke tests is performed. These tests exercise the most basic or core functionality of the product to determine its overall health. Think of it in terms of going to see the doctor. Your doctor always checks your weight and blood pressure, listens to your heart, and pokes around in your ears and throat. Once general health has been established, more detailed testing can be performed.

Team Foundation Server provides team build capabilities that elevate "build" to a first class object. Build configurations are defined within Visual Studio (see Figure 3) and can be executed on a scheduled basis or initiated on demand. Team Foundation Server utilizes the MS Build platform, which allows for maximum flexibility in customizing the build process to your environment.

Figure 3. Build Configuration

By utilizing the test automation capabilities provided in Visual Studio Team Edition for Software Testers, the smoke tests can also be automatically executed after the compile/linking steps of the build have been completed. These tests can include not only functional tests on the built application, but also static analysis testing on the source code to identify coding issues such as security holes or memory leaks.

Builds can be executed on any build machine. However, all of the build information is collected and stored in the Team Foundation Server database and is available to team members both inside Visual Studio or on the team project Web site. Again, it is the integrations where the real power of Team Foundation Server comes into its own. The build report, which is automatically generated, contains not only the status of the build and where testers can go to find the results, but also the work items that went into the build. Through automation and the simple link between source code and work items, Team Foundation Server can trace back from the build to the source code changes and produce a list of the work items that were added since the last build. One final piece of integration automatically updates to the work item field "Integrated In Build" so that build information is available from the work items themselves.

This is extremely helpful to both developers and testers. Testers now have a clear roadmap of what new capabilities or resolved bugs they can validate for any given build. Developers can also see when their changes got incorporated into the team build and verify the fixes themselves. This is particularly important for large teams where it may take a day or two for a change to go through several levels of integration and get into the "official" build.

I also want to draw your attention to the link between tests and work items. We all know that testers find bugs and submit those bugs into a bug-tracking tool. The problem today is that it is often hard for the tester to include enough information in the bug to allow the developer to reproduce the problem. Thus, developers will either mark the bug as "not able to reproduce," or they need to go to the tester's office to try and debug the situation on the tester's machine.

With Team Foundation Server, testers can submit bugs (or other work item types) directly from a failed test case in Visual Studio. Work items submitted in this way capture all of the testing information, automatically making it much easier for the tester to enter a work item. Information about the failed test is now readily available to the developer. He or she can review the test failure information and rerun the specific test quickly. Additionally, in the case of performance and load testing, a developer can step through the test run and look at various performance counters (some of which the tester may never have looked at personally). Storing and communicating load test run information allows performance investigations to go pretty deep before the developer needs to rerun the test.

The treatment of source code, work items, builds, and tests as first class objects in the system is critical for any life-cycle tool. Team Foundation Server goes one step further and focuses on the integrations between these objects and delivers on the automation possibilities these integrations provide. This delivers improved productivity for both developers and testers, and significantly reduces the communications issues between individuals performing these roles on a software team.

Project Management

Of course a software team would not be complete without the individuals who do the work of defining what the product should do and managing the teams to deliver on time and on budget. Team Foundation Server has been designed to improve the collaboration, communication, and management of software development teams. There are several capabilities for both the project leader and the requirements definer (a.k.a., analyst, program manager, or product manager). Central to these roles is the concept of the team project discussed previously. With both the team project and methodology, Team Foundation Server already delivers a set of work item types and a team project Web site populated with project templates and process guidance customized for your team and your organization. But what objects other than work items are interesting to the project manager/analysts? One that comes to mind is a project plan. A close second is specifications or requirements. Many software development efforts start with a high-level vision document and an Excel spreadsheet of key work items, including things like priority, development effort estimate, and a brief description. These could take the form of functional requirements, scenarios, or quality of service requirements. In any case, you can usually find an Excel spreadsheet being used on projects to track these important items, issues, or other things. Team Foundation leverages the power of Excel for its ease of entry and tracking, but integrates the locally stored XLS files more formally into the overall development environment by linking them directly to work items in the Team Foundation Server database.

Analysts using Team Foundation Server can start editing in Excel and then "publish" their lists to Team Foundation Server, creating new work items that can be tracked. They can continue to use Excel to update these items by synchronizing their spreadsheets with the existing work items database. Communicating work items and keeping lists up to date suddenly becomes much easier and more practical.

It is also possible to create new spreadsheets from data in the work item tracking system. Say you need a quick graph for a presentation you are doing in an hour. With Team Foundation Server, you can create a query for all the Priority 1 Bugs and Tasks that are active on Team Projects A and B. From this query, you can select "Open in Microsoft Excel" and then build a graph quickly based on this data.

The possibilities are endless, and the support for the Excel scenario has been well designed and thought out. For example, you can take work items offline by exporting them from Team Foundation Server to Excel and making changes while you are on the go. Edit owners, change priorities, and add new items. Then when you connect back up, all this data is synchronized to the work item database.

You might be asking yourself, "What if others have made conflicting changes to the same work items while I am off-line?" The answer is that an easy-to-use compare/merge utility will help you resolve any of these conflicts.

Figure 4 shows you the project queries in the Team Explorer and the work item results list inside Visual Studio. Note the "Open in Microsoft Excel" button at the top of the results grid. Figure 5 shows the same work items as they appear in Excel. Note the toolbar that supports getting a different set of work items or synchronizing the current work items with the Team Foundation database.

Figure 4. Work Items in Visual Studio

Figure 5. Work Items in Excel

Project managers may be less worried about lists and requirements than they are about schedules. To support the project manager, Team Foundation Server provides a similar integration with Microsoft Project. A project manager can break down a project plan, schedule and assign tasks, and then "publish" these into the work item database, creating new work items of type "task" or whatever work item type makes sense for your organization. Just like Excel, there is bidirectional synchronization, which allows project managers to work offline in MS Project and take advantage of MS Project's scheduling and resource leveling services to manage their projects. How nice it would be if developers could just enter updates in Visual Studio, and when they synchronized, they would have that information updated in their project plans. Team Foundation Server makes this possible.

What if you wanted to organize tasks by project iterations and also by product structure? With Team Foundation Server, work items can be categorized both by iteration and product structure. In MS project you can quickly change groupings to see both views, allowing you to switch between an overall project view and a view focused on the current iteration.

One of the main reasons projects fail is project managers lose track of the real status of their projects. Unintegrated project plans quickly drift out of date and tracking bugs (typically the only real-world data available on which to make decisions) is inadequate. Decisions can become flawed due to this lack of information. Team Foundation Server keeps the project plan alive and makes it easier for team members to help the project manager keep things up to date.

Project Reporting and Metrics

Imagine your joy at seeing active bug counts dropping lower and lower. But what if you are not aware that test coverage is also falling while source code changes are continuing to increase? These trends would indicate a problem in testing that would not be caught if you were only focused on bug trends. The problem today is that this kind of information is not readily available, and when it is, it's usually only accessible in separate tools or independent reports.

Team Foundation Server provides cross-discipline integrated reporting, which gives you a more realistic view of the health of a software project. The Team Foundation Server warehouse is based on SQL Reporting Services. The warehouse collects data on all work items and their state, source code changes and churn, builds and build results, and test cases and test case coverage. Figure 8 shows a test effectiveness report by build. For each build, you can see the results of the automated tests, the amount of code changes that came into that build, and the code coverage of the tests. Watching these trends in addition to bug count can be incredibly helpful in identifying other project problems that need to be addressed.

You may have other data sources that you use to evaluate project progress. To support collection and reporting of external data, the Team Foundation Server warehouse is fully extensible, with an adapter architecture that can draw data on a periodic basis from other data sources in your organization. With Team Foundation Server reporting, you now have access to cross-domain reports, giving you much better visibility into the progress of the project. These reports can be run from within Visual Studio or from the team project Web site. Access and availability of these reports is another way Team Foundation improves the communication between you and your team.

Conclusion

Team Foundation Server is a software life-cycle tool designed specifically to improve software development team collaboration and increase productivity. Team Foundation Server delivers version control, work item tracking, project management, and build management capabilities. Above all, it focuses on the linkage between the central objects a software team manages, and on the unique integration and automation possibilities these links provide.

More information can be found at https://msdn.microsoft.com/vstudio/teamsystem.

About the author

Brian A. White has a decade of hands-on experience with software configuration management tools and methods. During his career, he has deployed SCM solutions in the industrial controls and telecommunications industries, many of them to meet ISO 9000 and SEI CMM objectives. He is currently director of enterprise change management product strategy for IBM software group. Publications Book Published: Software Configuration Management Strategies and Rational ClearCase: A Practical Introduction (TheADDP9 Object Technology Series)

© Microsoft Corporation. All rights reserved.