[Editor's Update - 1/20/2006: This article refers to a beta version of Visual Studio 2005. An updated version of the article, reflecting features found in the final release of Visual Studio 2005, can be found at Team Up: Get All Your Devs In A Row With Visual Studio 2005 Team System.]

Team Up!

Get All Your Devs in a Row with Visual Studio 2005 Team System

Chris Menegay

This article is based on the Visual Studio 2005 December Community Technology Preview. All information contained herein is subject to change.

Contents

Project Methodology
MSF Agile
Creating a Team Project
Project Plans and Work Items
Project Documentation
Design Your Application
Team Foundation Version Control
Writing Better Code
Managed Code Analysis
Unit Tests
Load Testing
Testers, Manual Testers, and Bug Tracking
Team Build
The Team Site and Reporting
Conclusion

Software development is generally recognized as a difficult process. Numerous studies have been conducted and volumes of books have been written on how to improve the process of developing applications to yield better and more consistent results. The difficulty has never been in coming up with new and better ideas to develop software. Rather, the difficulty is in taking those ideas and implementing them in meaningful ways in the real world. With Visual Studio® 2005 Team System, Microsoft is taking an important step in helping development teams build robust software systems.

Team System extends the power of Visual Studio 2005 with a new source control system. Team System also includes unit testing and code analysis tools to help developers. However, Microsoft has broadened its focus from just developers, and now includes tools to support the entire development team. Team System includes tools to help project managers, architects, developers, testers, and even development managers. Team System contains a new work item tracking system to manage development tasks, as well as the implementation of process, and a Web portal to allow a level of transparency to the development process.

In this article, I'll give an overview of Team System using the Visual Studio 2005 December Community Technology Preview (CTP). I'll show you how to set up a development project and explore all the steps of the development process through to testing. Installing the version of Team System that is included with the December CTP is a slightly more difficult process than the one that will be required when the product ships in its final form. The CTP supports a very specific environment that requires multiple machines, or multiple virtual machines, to install. The installation guide that comes on the DVD or in the download is accurate, but you may need some additional help to get things working properly. You can also refer to my notes, as well as those of a few others, posted at the following blogs: weblogs.asp.net/cmenegay, blogs.msdn.com/robcaron, and blogs.msdn.com/askburton.

Project Methodology

In the past, Visual Studio was solely a tool for developers. Because of this, it provided little value for the other phases of a development project, such as requirements gathering, design, and testing. However, Team System was designed to support more than just the developers. It is meant to support the whole development lifecycle, and the people involved in that lifecycle.

One of the best things about Team System is that it is built with an understanding of process. Beyond the idea that having some form of process might be a good thing, Microsoft made very few assumptions about what your process would be, and has therefore built in a great amount of flexibility. Team System uses what Microsoft refers to as "methodology templates" to define processes. You can develop your own methodology, use one of the methodologies that will ship with Team System, or even acquire a third-party methodology template.

In the past, many development groups have not implemented formal processes because the investment in both time and money to adopt and enforce a formal process was too great. With Team System, the process will be a part of the tools that teams use every day, making it much more approachable for a broader set of development teams.

[Editor's Update - 3/24/2005: MSF Formal has been renamed to MSF for CMMI Process Improvement, and MSF Agile has been renamed to MSF for Agile Software Development.] Both of these methodologies are implemented as templates and integrated into Visual Studio. The December 2004 CTP only included support for MSF Agile. It is quite likely that organizations that have a formal process will move their existing processes into Team System, while organizations that have not previously implemented a formal methodology will use either MSF Formal or MSF Agile.

Not all members of the development process, however, will have, or even desire, Visual Studio. To meet the needs of non-developers, both a Project Portal and a Team Foundation Client are also slated in order to access many of the features of Team System that would be desired by a broader audience. Team Foundation Client will essentially be a version of Visual Studio 2005 with all the development features removed while retaining all the Team System features. This means that most of the processes covered in this article should apply to Team Foundation Client as well.

MSF Agile

MSF Formal is a process designed to help achieve CMMI Level 3 Compliance, while MSF Agile is meant to be more flexible and is iterative by design. No single process will be an ideal fit for all projects, so it is possible that organizations will adopt a process based on the needs of a particular development effort. An early view of MSF Agile is available for download at MSF for Agile Software Development.

MSF Agile supports the following five roles: Architect, Business Analyst, Developer, Project Manager, and Tester. As you read through the upcoming paragraphs about process and team development, keep in mind these five distinct roles, as well as business users/sponsors and IT management. Team System has features that will appeal to all of these unique types of individuals.

Creating a Team Project

Now that I've laid some groundwork for the overall purpose behind Team System, I'd like start walking through the process of setting up what is called a portfolio project in the Beta 1 Refresh (it will be called a team project in subsequent releases). After loading up the Visual Studio 2005 December CTP, you first need to connect to a Team Foundation Server (TFS), which should be running on some other system or virtual machine. TFS is a server platform that provides many of the team features of Team System. Some of the features that TFS provides are the new source control system, work item tracking and the team portal site.

To connect Visual Studio to a TFS machine, under the Tools menu is an option to "Connect to Team Foundation Server." The installation notes will assist you in getting connected to your TFS machine. Once connected, you will see the Team Explorer window. Team Explorer is your view into TFS, much like Server Explorer provides insight into a SQL Server database. Team Explorer is a great tool. You will want to become familiar with it as soon as possible, as you will be using it regularly.

Once you are connected to TFS, you can create your team project. Team projects are one of the key benefits of TFS. A team project is a single place to access and work with all of your project-related artifacts, including design documents, work items, and project plans. You will create one team project for each development project on which you are working. To do this from the Team Explorer, use the "New Team Project" toolbar button. Alternately, from Team Explorer you can right-click your TFS Server and create the team project from there. You also have the option of adding an existing team project to your Team Explorer window. When setting up the team project, you must choose which methodology template you would like to use, as shown in Figure 1. In addition, you have the option of setting up a new source control folder, or branching an existing code base. I will use MSF Agile for my examples.

Figure 1** Creating a New Team Project **

When you set up a team project several things happen. One key item is the creation of a Windows SharePoint® Services (WSS) team site. TFS integrates with WSS to provide many of its document management capabilities. WSS also has collaboration features that can be leveraged by TFS. If you open your browser and go to https://tfsserver/sites/project, you will see the home page for the team site created by TFS. This is a WSS site, which is accessible by anyone with the proper permissions. It is a great way for business users and management to gain access and insight into the status of a project.

Once you have a team project, you may want to configure your project before going any further. You do this via the Team Explorer by right-clicking your project and selecting Team Project Settings | Classifications. The Settings menu option allows you to set security permissions and source control policy as well as set up your project structure. If you select MSF Agile, you currently have three iterations added for your project by default. You can rename these, remove them, or add more. For example, if you want to have six phases of incremental rollouts, you can set these up as iterations. Later on, when you are creating work items, they can be associated with a particular iteration in your overall project. Remember that the methodology templates are under your control, so don't feel confined by the process.

Project Plans and Work Items

One of the key benefits that Team System provides from a project management perspective is a feature called work item tracking. Features such as unit testing, better source control, and code analysis are what get developers excited. Project managers, business stakeholders, and IT managers, on the other hand, are going to be especially excited by the work item tracking feature which does exactly what the name implies. Each and every task that needs to take place in the software development process can be treated as a work item. These include documentation tasks, design tasks, development tasks, bugs, or requirements. At this point you may be thinking that you already manage your work items as tasks in Microsoft Project, or even Excel. But the truth of the matter is that most people are really only creating tasks in these tools, and not actually tracking or managing them.

Taking into consideration your current tracking process, think about your answers to the following questions: Are the design documents complete? How many tasks are assigned to a particular developer? What tasks have been completed? Which of the tasks are furthest behind? What is the impact on on the schedule when tasks are not completed on time? Granted, many organizations already have the ability to answer these questions. However, in order to do so, a good deal of communication must take place between the project manager and the rest of the team, including developers, business analysts, and testers. The project manager must talk to all of these different people to accurately assess project status. Keeping track of the status of tasks is usually accomplished with project status meetings, individual conversations, or via e-mail. One of the goals of Team System is to streamline this process of data collection, tracking, and reporting.

Once you select a methodology template to use (as you'll recall, I chose MSF Agile), several tasks (work items) are automatically created on your behalf. This is done because in the MSF Agile process certain tasks need to be accomplished. Figure 2 shows an example of the work items that were created when I set up my team project using MSF Agile.

Figure 2** Work Items in MSF Agile **

Work items are very similar to tasks in Microsoft Project in that they can be assigned to people. They have a status as well as duration. As people complete their work items, they can change the status of those work items and have that status reflected on the WSS team site. The WSS site utilizes SQL Server™ Reporting Services to show various reports based on the data stored in SQL Server by TFS. You will have the ability to create your own reports as well that are then integrated into SharePoint using custom Web Parts. Note, however, that these reports are not available as part of the December 2004 CTP.

Project Documentation

Based on the MSF Agile approach, one of the first steps in the process is to start creating some documentation. Depending on where you are in your process, this documentation could be a business case, a scenario, or even a project plan. The documentation you create will depend on your methodology. To create these documents in the context of Team System, you use the Team Explorer (alternately, you could do this through the team portal site). If you drill down into the Documents node, you will be able to right-click and select Add a Document. When you specify which methodology to use for your project, Team System configures the appropriate templates that will be used for the various documents of your project. When you then select Add a Document, you will be prompted to choose the type of document you want to add by selecting the appropriate template. Templates include options for Design, Lifecycle, Plans, Project Management, and Requirements Scenarios and Features. Once you've selected your template, you will edit your document in the appropriate tool (Microsoft Word or Excel, for example).

The documents that are created are stored in the WSS site that hosts your project. This allows people within your organization to access the documentation simply by navigating their browser to the appropriate site. Documents added directly to the portal site will be shown in Team Explorer. To see newly added documents in Team Explorer, right-click the Document node and select Refresh.

At some point, the project manager will want to create an actual project plan. With Team System, there is some real fun to be had doing this, assuming of course that you find creating project plans and tracking tasks to be loads of fun. At the very least, Team System makes the management of your project much more simple, which to me translates to exciting!

The process of creating a project plan is fairly straightforward in Team System. You do this from Team Explorer by navigating to Documents | Project Management and right-clicking. Here, the context menu contains an option to Create Microsoft Project Plan. Team System also supports tracking your project tasks in Excel spreadsheets, and you would create a spreadsheet for your project tasks in a manner similar to this.

A real benefit of Team System is its relationship with Project or Excel. When you install Visual Studio 2005 December CTP on a computer that has Microsoft Project or Excel installed, you will get some additional features added to these applications. Specifically, you will have a Work Items menu as well as a new toolbar that allows you to interact with a Team Foundation Server. The key feature is that you can synchronize your project plan tasks with work items within Team System.

The process begins with creating a project plan and importing the original work items that were created as part of the team project creation. You then add and assign additional tasks, and synchronize the project plan tasks with Team System's work item database. As developer's work on tasks and check code into source control, they will update the status of the work items from within Visual Studio. Work item status data will be available on the team portal site via work item reports. Project managers can then synchronize their project plans with the work item database to keep their information current and acquire the latest status.

Figure 3 shows Microsoft Project with the work items from Team System imported in and used as Project tasks. You will notice a new toolbar for interacting with a Team Foundation Server. This integration is available in Excel as well as in Project. This was added based on customer feedback, to accommodate users who choose to manage their project tasks in Excel rather than in Project.

Figure 3 Importing Work Items into Microsoft Project

Once the project plan is ready, it should be synchronized with Team System so that the project team members will know what their assignments are. If you are a developer, the elegance of this is that you receive your work item list without ever leaving Visual Studio. You simply navigate to Work Items in Team Explorer and open up My Work Items or My Active Work Items. This streamlined approach puts little burden on the developer as well as requiring fewer meetings between project managers and developers.

Design Your Application

From the developer perspective, once work items for development tasks have been assigned, you are ready to begin designing your application and writing code. Hopefully, one or more of the tasks on the project plan actually accounts for the design phase of your application. Notice that I mention designing before writing code. Team System comes with some great design tools that you should consider using. I won't go into the designers here; instead for more information I will refer you to Brian A. Randell and Rockford Lhotka's article, "Bridge the Gap Between Development and Operations with Whitehorse," in the July 2004 issue of MSDN®Magazine.

Team Foundation Version Control

Before creating any designs or code, you will want to set up source control using Team Foundation Version Control. Formerly known by its code name "Hatteras," Team Foundation Version Control is a much more robust platform than Microsoft Visual SourceSafe®. All of the content you store in this new source control system is automatically backed up in a SQL Server 2005 database for easy administration. The design goals for this new source control system include high scalability and performance, two features that are lacking in Visual SourceSafe. The new source control system will include more robust branching and merging capabilities. Because of this, multi-checkout will be turned on by default.

A new feature called "shelving" is also available. This feature allows you to take checked-out code that you are working on and check it into source control, but not into the primary branch, allowing developers to properly back up their work without forcing incomplete changes onto other developers on their team.

Visual SourceSafe will still be available and updated to work with Visual Studio 2005. Visual SourceSafe may prove useful on smaller projects with smaller teams that don't require the power of Team Foundation Server and that don't want to put forth the extra effort and expense of installing it. To select which source control engine you want to use, simply open Visual Studio, go to Tools | Options and select Source Control options.

Once you are configured to use Team Foundation Version Control, any time you create a new project in Visual Studio, you will have the option to add the project to source control. At that time, you will select the Team Foundation Server you wish to use. As a developer, when you are working on tasks you can mark work items to associate the work items with code that you are checking into source control. This association is then stored in the database and can be used later to create build reports. In addition, the new source control system also allows the creation of check-in policies. The purpose of a check-in policy is to restrict what code is allowed to be checked into the source control repository.

Writing Better Code

Visual Studio 2005 Team System integrates within the IDE several tools that will help you write better code. These include a profiler to analyze potential performance problems in your application, code analysis tools for both managed and unmanaged code, and unit testing tools with code coverage analysis. The code analysis tools are based on technology that has been in use at Microsoft for some time, but never so nicely integrated with Visual Studio. Native code is analyzed using PREfast, while managed code is analyzed using FxCop. The unit testing tools are very similar to what is available in tools such as NUnit, but there is greater ease of use and the time to create tests has decreased. This makes unit testing much more approachable. The unit tests also integrate nicely with code coverage, which is essentially a reporting mechanism to let you know how much of your code was actually exercised by your unit tests.

Managed Code Analysis

If you are familiar with FxCop, you'll be comfortable with the managed code analysis capabilities of Team System. The integration with the IDE is excellent. To enable Code Analysis, simply go to the properties for your project, then go to the Code Analysis tab. From there you can enable Code Analysis as well as select which rules you wish to run. Most organizations will likely disable a number of the provided rules, as the rules that come with Code Analysis are very strict. Indeed, it is a humbling experience to run FxCop against one of your existing applications to see how noncompliant you are with its rules.

The great part about Code Analysis being integrated with the IDE is that, once turned on, it will automatically run when your application is compiled and give you warnings or errors as part of the build process. You do have the ability to turn Code Analysis on for Release builds and off for Debug builds, which is a nice feature. Be aware that running Code Analysis can take a bit of time on larger projects. The other nice feature that's available is the option of running Code Analysis as a check-in policy for source control. This allows you to prevent developers from checking code that has not passed the FxCop validation rules into the source control repository. Check-in policy comes with an override mechanism to allow code to be checked in, but the override can be logged.

Unit Tests

The general concept behind unit testing is to run isolated pieces of code in your application and test to see if they yield the desired result. This usually equates to calling a method with a variety of controlled inputs, and testing the returned data. This can easily be done without any kind of tool support, but to make it productive, some assistance is needed. Some traditional problems with unit testing are the creation of the tests, the organization of the tests, and having a mechanism of easily reporting the success or failure of those tests. Team System addresses all of these problems.

[Editor's Update - 3/24/2005: This capability is only available for managed code.] Attributes are used to differentiate unit test code from regular code. Within the IDE are tools to both organize your tests into test lists as well as to execute tests based on those test lists. When you execute your tests, the results are shown in Visual Studio in a Test Results window.

To implement unit tests in your project, simply right-click in your code and select Create Tests, as shown in Figure 4. You will be prompted to select which methods on which objects you want to create tests. You can create multiple tests at one time by selecting methods from multiple different classes. The tests that are automatically generated will contain code to instantiate the object that contains the method to be tested, declare variables for method parameters, and finally call the method to be tested. By default, the tests will return a result of Inconclusive. You can change this under the Configuration tab when creating the tests. Inconclusive means that it is not known whether the test succeeded or failed. This is done to remind you that you need to actually put some logic into your tests. Consider the following example of a method to be tested:

Public Class Math Public Function Add(ByVal Value1 As Integer, _ ByVal Value2 As Integer) As Integer Return Value1 + Value2 End Function End Class

In this example, the Add method simply returns the result of adding two integers. When you first create your unit test, the generated test code will look similar to that shown in Figure 5.

Figure 5 Generated Test Code

''' <summary> ''' AddTest is a test case for Public Function Add(As ''' Integer, As Integer) ''' </summary> <TestMethod()> Public Sub AddTest() Dim target As NewOrderEntry.Math = New NewOrderEntry.Math ' TODO: Initialize to an appropriate value Dim Value1 As Integer ' TODO: Initialize to an appropriate value Dim Value2 As Integer Dim expected As Integer Dim actual As Integer actual = target.Add(Value1, Value2) Assert.AreEqual(expected, actual) Assert.Inconclusive("Verify the correctness of this test method.") End Sub

Figure 4 Creating Unit Tests

To run your test, you must first compile your project and then open up your Test Manager window. Test Manager can be found under the Test | Windows menu, and allows you to view your various tests and select which tests you wish to run. The Test Manager also allows you to add your tests to the various test lists that you create. For instance, you may want to group together all tests that are used to exercise your business logic, or your data access code. Alternately you could group your tests by functional areas within your application.

When you run your tests, you have several options. One option you should consider is turning on code coverage, which lets you capture and analyze data showing what code was executed by your unit tests. The code coverage option is part of the test run configuration. From the Test Manager, the toolbar button Edit Test Run Configuration allows you to select and edit a set of configurable options for running your tests. After running your tests, there are two things you should review: the test results (see Figure 6) and the code coverage results (see Figure 7).

Figure 7 Code Coverage Results

Figure 6 Test Results

You will notice that the Test Results window indicates that my one test was inconclusive. This is because I didn't change the generated test to do anything useful. The test should be changed to something similar to that shown in Figure 8.

Figure 8 Revised Test Code

''' <summary> ''' AddTest is a test case for Public Function Add(As Integer, ''' As Integer) ''' </summary> <TestMethod()> Public Sub AddTest() Dim target As NewOrderEntry.Math = New NewOrderEntry.Math Dim Value1 As Integer = 32 Dim Value2 As Integer = 10 Dim expected As Integer = 42 Dim actual As Integer actual = target.Add(Value1, Value2) Assert.AreEqual(expected, actual) End Sub

In Figure 8, the code assigns the two parameter values to two integers and checks the return value of the Add method to be sure that it is as expected. If the value returned from the Add method is 42, the correct answer, the test passes; if not, the test fails. You also have the ability to create data-driven unit tests. This will allow you to use actual data from a database, rather than hardcoding values.

Unit tests are only useful if they are written to accurately exercise your code. If you have 1000 lines of code and only execute 10 lines with your unit tests, then your unit tests don't give an accurate representation of how good your code is. The code coverage capabilities of Team System are a great resource to determine if your unit tests are covering the majority of your existing code, and conversely to determine if there's any existing code that you'll never use and that can thusly be removed.

In addition to the Code Coverage Results view, you can also turn on color coding of your source code. Figure 9 shows two pieces of code. The code in red was not executed by the unit tests; the code in green was executed.

Figure 9 Code Coverage Source Highlighting

The test results and code coverage results can be published to your Team Foundation Server which, in turn, stores the data in the database. This allows reports shown on the portal site to use this data to give a representation of where the project stands from a testing and code quality perspective.

Load Testing

In addition to unit testing, Team System also provides the ability to create, manage, and run Web load tests. This functionality is very similar to what was previously provided by Application Center Test, only much more robust, scalable, and entirely integrated with Visual Studio. You have the ability to create your own tests from scratch, as well as to record a Web browser session for later playback on one or multiple PCs. Some nice features are included in the load test tool. In particular, the tool has the ability to handle ASP.NET forms authentication in addition to the ability to properly handle ASP.NET ViewState.

To use the load testing capabilities, the easiest way is to create a new Test Project. This is a new project type that you can add to your solution. Once that is done, you can add multiple new tests by right-clicking the project in Solution Explorer and selecting Add New Item. Recording a Web load test is as easy as adding the appropriate type of test to your project and selecting Record to initiate the record process. As you create new tests, they will show up in the Test Manager window along with your unit tests, providing you with one complete view of the various tests for your project. Web tests are distinct from load tests in Visual Studio 2005. A Web test is the script that exercises a particular portion of a Web application. A load test is a separate test that contains the appropriate data used to simulate load, such as number of users to simulate. You therefore create Web tests and then use them in a load test to stress your Web application.

Testers, Manual Testers, and Bug Tracking

While Team System provides unit testing and load testing of Web applications, it does not provide an automated mechanism to test non-Web user interfaces (though Compuware has announced the integration of its TestPartner product to provide testing for rich client user interfaces). Your QA team is supported by having built-in test management tools, as well as a bug-tracking system. Bugs are simply a particular type of work item, and are entered into Team System and assigned as a task for someone to work on. The status of bugs, as well as bug counts, will be viewable from the project portal site.

Another great feature is the ability to store and manage the various manual tests that exist for a project. You are likely familiar with the various Word documents and manual scripts that often get created to detail the steps required to manually test a system. Team System allows these scripts to be stored as manual tests in TFS and managed alongside your Web tests and unit tests. These scripts can be actual Word documents or plain text. There is also the capability to execute these tests from within Visual Studio.

When these tests are selected to be run, their status is pending until a tester steps through the manual process and marks the test as having passed or failed. Obviously, a bug would likely be entered if the test fails. The manual tests can also be grouped using test lists to provide for some great organization capabilities. Having the tests in TFS allows developers easy access to these tests as well if they need to repeat the steps that were followed to duplicate a bug. These new tools really pull the testers and the developers into the same environment to allow them to work better together.

Team Build

Another tool you have in your toolkit with Visual Studio 2005 is Team Build. Team Build utilizes MSBuild, which is the new extensible build engine that ships with the .NET Framework 2.0. Team Build supports the concept of a build server. This build server will listen to network requests that will direct the build server to build the application using build scripts that are stored in Team Foundation Version Control. The build scripts can be generated from Visual Studio using a wizard to select various build options. These options include having FxCop or unit tests run as part of the build process. You can also have work items updated and notifications sent as part of the build process. For instance, you could have a nightly build process to automatically compile your application, run unit tests and static analysis, and then finally put the new build on a test server and notify testers of the availability of a new build.

The Team Site and Reporting

Aside from the developer-oriented features of Team System, the important visibility it brings to those outside the immediate development process should be noted. This includes managers, project managers, testers, business users, analysts, and anyone else that may have interest in the status of a development project. While testers and project managers may have access to Team Foundation Server by using the Team Foundation Client, it isn't realistic to assume that business users and IT management would be running Team Foundation Client.

The SharePoint home page for your project is the perfect tool for these individuals. From this site they are able to access the current status of the project, review the number and severity of bugs, and access the project documentation. In addition, various reports will be available. These will include reports for outstanding work items, outstanding bug reports, test results, and many others. This added visibility should provide a much greater insight into the development process than what has previously been available.

Before I finish, I should make one point about extensibility. For organizations that have existing development processes already in place, Team System was designed to support customization. Team System was also designed with the idea that third-party companies would be able to integrate and extend it. Borland has already announced that they will be delivering a version of their CaliberRM requirements management tool that integrates with Team System. This fills a gap in the Microsoft product suite. If Team System doesn't meet all of your needs, however, be sure to look for the appropriate tools that integrate with and extend it.

Conclusion

Visual Studio 2005 Team System will be purchased in a different manner than Visual Studio is purchased today. I want to make this distinction since the beta builds don't accurately reflect the variety of products that will be available when the product is officially released. Most notably, Team Foundation will be a separately purchased server product. There are already several feature walkthroughs available and more will be released during the beta cycles. If you have been considering putting more "process" into your development efforts, then you should consider investigating Team System to see if it meets your needs.

Chris Menegay is a founder and principal consultant with Notion Solutions. Notion Solutions is a training and consulting firm based in Dallas, Texas that specializes in Microsoft technologies. You can reach Chris at weblogs.asp.net/cmenegay.