Team Up

Get All Your Devs In A Row With Visual Studio 2005 Team System

Chris Menegay

Contents

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

Software development is generally recognized as a difficult process. Numerous studies have been conducted and volumes of books 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. 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. More importantly, though, Microsoft has broadened its focus from just developers, and has now included tools for project managers, architects, developers, testers, and even development managers. Team System contains a new work item tracking system to manage tasks, tools for implementing process, and a Web portal to allow a level of transparency to the development process. In this article, I'll show you how to use Team System throughout your software development lifecycle. I will cover both the client tools available with Visual Studio Team Suite and the server features enabled by Team Foundation Server.

Project Methodology

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 ships 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 was too great. With Team System, process is a part of the tools that teams use every day, making it much more approachable for a broader set of development teams.

Microsoft has an established development process called the Microsoft® Solutions Framework (MSF). MSF has not been widely adopted across a broad base of developers, even at Microsoft, possibly because it is viewed as difficult to learn and use. Microsoft has updated MSF to version 4.0 and has shipped Team System with two different versions of MSF 4.0: MSF for CMMI Process Improvement, which emphasizes process over people, and MSF for Agile Software Development, with an emphasis on people over process. Both of these methodologies are implemented as templates and are integrated into Visual Studio. 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 one of these two versions of MSF. From my experience, organizations are usually best off using one of the MSF processes as an example and customizing it to match the way they currently do software development. I discourage customers from adopting a new process at the same time as implementing Team System. One of Team System's greatest strengths is its ability to help you follow your process and to collect data during the software lifecycle that can be used for process improvement. The process integration within Team System is enabled within Visual Studio using a work item tracking system I will cover later in this article.

Not all members of the development process, however, will have, or will even desire to have, Visual Studio installed. To meet the needs of non-developers, Microsoft provides a project portal and a client for Team Foundation Server called Team Explorer. Team Explorer is essentially a version of Visual Studio 2005 with all the development features removed while retaining all the Team System features. When installed on a computer already running Visual Studio 2005, Team Explorer integrates into the existing installation. Most of the processes covered in this article apply to Team Explorer as a standalone tool and when integrated with Visual Studio 2005. For the purposes of this article, it will be assumed that you have Visual Studio 2005 Team Suite, which has the entire set of client features of Team System included in one installation.

MSF for Agile Software Development

MSF for CMMI Process Improvement is a process designed to help customers who are looking to achieve Capability Maturity Model Integration (CMMI) level 3 compliance, while MSF for Agile Software Development 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 processes based on the needs of the particular development efforts.

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

Creating a Team Project

Now that I've laid some groundwork for the overall purpose behind Team System, I'd like to start walking through the process of setting up a team project. Team projects are not the same thing as Visual Studio projects. A team project is created to support a software development effort. It is usually best to think of a team project the way your customer thinks of a project. The customer is aware of the project name, a set of requirements, a set of bugs, and some code somewhere hidden away.

After loading up the Visual Studio 2005 Team Suite, you first need to connect to a Team Foundation Server, which is a server somewhere on your network. Some of the features that Team Foundation Server provides are the new source control system, work item tracking, and the team portal site.

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

Once you are connected to Team Foundation Server, you can create your team project. 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. Alternatively, from Team Explorer you can right-click your Team Foundation 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 process template 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 for Agile Software Development for my examples.

Figure 1** Choosing a Process Template **

When you set up a team project, several things happen. One key item is the creation of a Windows® SharePoint® Services (WSS) team site. Team Foundation Server integrates with WSS to provide many of its document management capabilities. WSS also has collaboration features that can be used by Team Foundation Server. If you open your browser and go to https://tfsserver/sites/project, you will see the home page for the team site created by Team Foundation Server. This is a WSS site, 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 | Areas and Iterations. 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 for Agile Software Development, 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 process 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 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, and development tasks, as well as dealing with bugs and requirements. You may be thinking that you already manage your work items as tasks in Microsoft Project, or even Microsoft 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 the schedule when tasks are not completed on time? How long is it taking to close bugs?

Granted, many organizations already have the ability to answer these questions. But 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 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 process template to use (as you'll recall, I chose MSF for Agile Software Development), several tasks (work items) are automatically created on your behalf. This is done because in the MSF for Agile Software Development 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.

Figure 2 Work Items in MSF for Agile Software Development

Work items are very similar to tasks in Microsoft Project in that they can be assigned to people. They have a status and may also have duration. As people complete their work items, they can change the status of those work items and have that status reflected in the project plan and 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 Team Foundation Server. Team Foundation Server stores data about your work items, your test results, your source control, and your build results in SQL Server 2005, and a reporting warehouse exists for analyzing the data. You also have the ability to create your own reports that can be integrated into SharePoint using Web Parts. Note that reports in Team System are provided by the process template. Therefore, the "out of the box" reports are the reports that come with MSF for CMMI Process Improvement and MSF for Agile Software Development.

Project Documentation

In the MSF for Agile Software Development approach, one of the first steps in the process is to start creating some documentation. This documentation could be a business case, a scenario, or even a project plan. The documentation you create will depend on your methodology. These documents will be added to the WSS site and viewable through Team Explorer's Document node for your team project. 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'll 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 on 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 Work Items with 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 and Excel. When you install Team Explorer on a computer that has Microsoft Project or Excel installed, some additional features will be added to these applications. Specifically, you will have a Work Items Team menu as well as a new toolbar that allows you to interact with a Team Foundation Server. The key feature is that you are able to 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 developers 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 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 and requires fewer meetings between project managers and developers. The work item queries shown in Team Explorer can be added to and modified. The initial list is created at project creation time based on the process template chosen.

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 Aaron Skonnard's column "Service Station: The Application Connection Designer" in the August 2005 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 stored in a SQL Server 2005 database for easy administration. This makes backing up your version controlled data as easy as backing up SQL Server 2005. 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 includes more robust branching and merging capabilities. Because of this, multi-checkout is 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. Shelving can be used for backing up incomplete work, sharing code for performing code reviews, or any number of other scenarios where it is useful to take code on one developer's hard disk and share it with the team.

Visual SourceSafe is still available and has been 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 them 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. Check-in policy should be seen as a strong encouragement to get the team to do things the "right" way. For example, one of the built-in policies requires a work item to be associated with the action of checking items into the repository. All policies can be overridden, but the policy violation will be tracked in the database.

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 was 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 needed 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.

Static Code Analysis for Managed Code

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 static code analysis, simply go to the properties for your project, then navigate to the Code Analysis tab. From there you can also select which rules you wish to run. Most organizations will likely disable a number of the provided rules, as they are very strict. Indeed, it is a humbling experience to run FxCop static code analysis against one of your existing applications to see how noncompliant your code is with its rules.

The great part about static code analysis being integrated with the IDE is that, once turned on, it will automatically run when your application is compiled, and it will give you warnings or errors as part of the build process. You also 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 static code analysis can take a bit of time on larger projects. Another nice feature is the option of running static code analysis as a check-in policy for source control. Finally, there is a built-in check-in policy for static code analysis. This allows you to discourage developers from checking code that has not passed the FxCop Static Analysis validation rules into the source control repository. Check-in policy comes with an override mechanism to allow code to be checked in, but, as with policy violation, 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 results. 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 how to easily report the success or failure of those tests. Team System addresses all of these problems, although the unit testing features are only available for managed code.

Team System provides the capability to automatically create unit tests for your methods. Attributes 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 Unit Tests, as shown in Figure 4. You will be prompted to select which methods on which objects for which you want to create tests. You can create multiple tests at one time by selecting methods from multiple classes. You will also be prompted to either create a new test project or to select an existing one. All tests must be created in a new project type called a "test project."

Figure 4 Creating Unit Tests

The testing framework within Visual Studio automatically discovers tests that are in test projects. The unit tests that are generated 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 Testing the Add Method

'''<summary>
'''A test for Add(ByVal Integer, ByVal Integer)
'''</summary>
<TestMethod()> _
Public Sub AddTest()
    Dim target As Business.Math.Math = New Business.Math.Math

    Dim val1 As Integer 'TODO: Initialize to an appropriate value

      Dim val2 As Integer 'TODO: Initialize to an appropriate value

    Dim expected As Integer
    Dim actual As Integer

    actual = target.Add(val1, val2)

    Assert.AreEqual(expected, actual, 
        "Business.Math.Math.Add did not return the expected value.")
    Assert.Inconclusive("Verify the correctness of this test method.")
End Sub

To run your test, you must first compile your project and then open up either the Test Manager window or the Test Manager View window. Both can be found under the Test | Windows menu and allow you to view your various tests and select which tests you wish to run (Test Manager is only available in Visual Studio Team Edition for Software Testers and in Visual Studio Team Suite). 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. Alternatively, you could group your tests by functional areas within your application. These test lists are stored in a file with a VSMDI extension in your solution. Later on, these lists will be used to run tests during your automated build.

When you run your tests, you have several options. One 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 toolbar menu, select Edit Test Run Configurations, and then select Local Test Run. This lets you select and edit a set of configurable options for running your tests. After running your tests, there are two things to 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>
'''A test for Add(ByVal Integer, ByVal Integer)
'''</summary>
<TestMethod()> _
Public Sub AddTest()
    Dim target As New Business.Math.Math

    Dim val1 As Integer = 32
    Dim val2 As Integer = 10
    Dim expected As Integer = 42

    Dim actual As Integer = target.Add(val1, val2)

    Assert.AreEqual(expected, actual, 
        "Business.Math.Math.Add did not return the expected value.")
 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 make sure the result is that which is 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 having to hardcode values. The documentation has a great example of using data-driven unit tests.

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 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 blue was executed.

Figure 9 Code Coverage Results

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.

Web Testing and Load Tests

In addition to unit testing, Team System also provides the ability to create, manage, and run Web tests and load tests. You can create your own tests from scratch, as well as record a Web browser session for later playback on one or multiple PCs. Some nice features are included in the load test tool. The tool has the ability to handle ASP.NET forms authentication in addition to the ability to properly handle ASP.NET ViewState. A Web test is the script that exercises a particular portion of a Web application. With Team System, you can easily send HTTP calls to remote servers and validate the responses coming back. The Web testing framework includes both validation and extraction rules. Validation rules use a set of criteria to determine whether a response coming from the remote server is valid. Extraction rules allow you to extract data from one response and pass that data along as a part of a subsequent request. As with unit tests, you can also have data-driven Web tests that pull data from a database and pass that data along to the remote Web application. You have the ability to create your own tests from scratch, as well as to record a Web browser session.

The load testing functionality is very similar in theory to what was previously provided by Application Center Test, only much more robust, scalable, and entirely integrated with Visual Studio. Load tests allow you to run Web tests and unit tests under load. Both Web and load tests are created as items in a test project. You can add multiple new tests by right-clicking the test 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. A load test allows you to select which tests you would like to run under load, select a user load, select a distribution of tests, and specify several other options. The purpose of the load test is to stress the hardware platform while monitoring the load on the machine. This is done by monitoring performance counters on the machines being tested. Several machines can be monitored during the load test. For distributed load testing, a load agent can be installed on machines and remotely controlled from a central controller. All data can be aggregated and seen from within Visual Studio. Keep in mind that you can also run unit tests under load. This type of testing can be very useful if you have unit tests that cover the data access portion of your application. By running these tests under load, you can simulate multiple users accessing your database at once.

Testers, Manual Testers, and Bug Tracking

While Team System provides useful tools for unit testing and load testing of Web apps, it does not provide a similar automated mechanism to test non-Web UIs (though various Microsoft partners have announced the integration of their products with Team System 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 these 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 Team Foundation Server 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 Team Foundation Server allows developers easy access to these tests 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. If a bug was created from the Test Results window, the results of the test will be attached to the bug. This provides easy access to the manual test being executed when the bug was filed. Lastly, code coverage data can be collected while running manual tests. This allows you to gain data on how much of your code is being executed by your manual tests. This data will let you know if you need more thorough manual tests, or perhaps that you have a lot of unused code in your application.

Team Foundation Build

Another tool you have in your toolkit with Visual Studio 2005 is Team Foundation Build. Team Foundation Build utilizes MSBuild, the new extensible build engine that ships with the .NET Framework 2.0. Team Foundation Build supports the concept of a build server. This build server listens to network requests that direct it to build the application using scripts stored in Team Foundation Version Control. The build scripts can be generated from Visual Studio using a wizard. Options include having FxCop static code analysis 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 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

An important part of Team System is the visibility it brings to those outside the immediate development process. This includes managers, project managers, testers, business users, analysts, and anyone else interested in the status of a development project. While testers and project managers may have access to Team Foundation Server by using the Team Foundation Explorer application, it isn't realistic to assume that business users and IT management would be running Team Foundation Explorer.

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 provides 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 with development processes already in place, Team System supports customization. Team System was also designed to be integrated and extended by third-party applications. If Team System doesn't meet all of your needs, be sure to look for the appropriate tools that integrate with and extend it. If you have been considering putting more "process" into your development efforts, investigate 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.