Lap Around Microsoft Visual Studio Team System 2005

Joel Semeniuk
Imaginets Resources Corp

September 2005

Applies to:
   Microsoft Visual Studio Team System 2005

Summary: This article introduces the features of Microsoft Visual Studio Team System and explains how they support the software development process. (25 printed pages)

Contents

Introduction
Team System for Software Architects
Team System for Software Developers
Team System for Software Testers
Team Foundation Server
Team System Extensibility and Customization
Conclusion

Introduction

Face it. Producing high-quality software on-time and on-budget is still a very difficult thing to do. Why is that, anyway? Let's start by admitting that software development isn't just about the software developers. In fact, there are typically many other roles involved in software projects, and the way they work together will determine the success of the project. Project teams typically consist of Project Managers, Business Analysts, Application Architects, Developers, and Testers. Unfortunately, in far too many cases, the people playing these roles find it challenging to coordinate their efforts, because they do not have tools that help them collaborate with each other. Wouldn't it be great if we had tools that not only allowed each team member to be more productive, accurate, and predictable in their work, but also to share information and collaborate more readily within their established software development lifecycle? Ladies and gentlemen, let me introduce Microsoft Visual Studio Team System.

Visual Studio Team System is Microsoft's newest addition to the Visual Studio family. This is a very significant release since, for the first time, Microsoft is targeting the entire software development lifecycle. Building on the features of Microsoft Visual Studio 2005, Team System provides additional features to support Architects, Developers, Testers, and Project Managers. Figure 1 depicts the four role-based versions of Team System: Software Architects, Software Developers, Software Testers, and Team Foundation.

Figure 1. Microsoft Visual Studio Team System

Team System provides a new set of tools that address a much broader perspective of the software development process, and also provides a platform to customize it to your own processes, extend it to new processes, and integrate it with existing tools and processes. The remainder of this article will explore the features of Team System and what it can do for your team and your process.

Team System for Software Architects

The features in Team Architect were the first to be publicly released in beta form, and were originally referred to by the codename "Whitehorse." These features, now called Distributed System Designers, make modeling an integral new capability of Visual Studio. These designers don't just create attractive diagrams—in fact, these new designers evaluate application and system design for deployment before writing any code. For example, application architects can design and evaluate service-oriented applications and application systems for deployment. Infrastructure architects can design logical representations of datacenters in which these applications will deploy. Both can then work together to ensure that the application design and datacenter design are compatible with each other. Code written to implement applications is kept synchronized with the application design. Some of the items you can model in Team Architect represent the beginning efforts of the Dynamic Systems Initiative (DSI) from Microsoft. For more information on DSI, see "Dynamic Systems Initiative."

All of the Distributed System Designers in Team Architect leverage the System Definition Model (SDM), an XML-based format that stores the model definition. SDM provides a common language in which both application systems and datacenter infrastructure can be described. This common language enables better communication between experts in each field, and allows an application to be validated to determine whether it could be successfully deployed and run in a target datacenter environment. The following sections describe the four Distributed System Designers that you can use in Team Architect.

Logical Datacenter Designer

The physical infrastructure of a datacenter is not normally significant to a developer who needs to understand what application hosting environments are present, and how they are configured, constrained, and connected. The Logical Datacenter Designer is used to create a logical datacenter diagram, which does not depict physical machines or even machine types in a datacenter, but instead is used to define or document specific configurations of application server software, such as Microsoft Internet Information Server, Microsoft SQL Server, or Microsoft BizTalk Server, and to show how these configured logical representations of (application) servers are interconnected. Logical servers can be grouped within zones that define logical communication boundaries. Zones can be configured to constrain the kinds of logical servers they can contain, and the direction and kinds of communication that can flow into and out of the datacenter. Table 1 lists the elements that can be modeled by this designer, and Figure 2 provides a simple example of a logical datacenter diagram.

Table 1. Logical Datacenter Designer Elements

Figure 2. Logical Datacenter Diagram (Click on the image for a larger picture)

Once you customize and add properties to the logical servers and zones in your diagram, you can then choose to add these shapes to the Toolbox for future reuse, by selecting one or more zones or servers, right-clicking, and clicking Add to Toolbox.

For each logical server or zone you place on your diagram, you can also specify a set of constraints and settings (from the View menu, click Other Windows and then Settings and Constraints). Here you can specify a policy of operating characteristics of each server that must be adhered to by applications that will be deployed on that server. For example, in Figure 3, the Settings and Constraints Editor is depicted for a server that only allows Form and Windows authentication as valid authentication mechanisms. You can see from the list of selected entries under the constraints heading that virtually any type of service could run on this server, from ASP.NET Web Applications, to BizTalk Web Services, to Generic Applications. This becomes important when we talk about the Deployment Designer later in this article. The tool also provides the ability to import the complete configuration of IIS, including Web site endpoints, from an existing server by right-clicking the logical server and clicking Import Settings.

Figure 3. Settings and Constraints Editor (Click on the image for a larger picture)

Application Designer

When I'm architecting a new solution, the first thing I do is attempt to visualize my solution on a whiteboard. From there, I continually refine my model until I'm ready to move on to deeper design, functional decomposition, and finally, construction. Application Designer will truly play a significant role in this processm, because now I can design and configure applications using a tool that understands what I'm building (unfortunately, my whiteboards just don't get it). Using the application diagram, I can decompose my solution into applications (units of code that could be deployed discretely, such as a Web service, a smart client, or Web site). Table 2 depicts some of the elements that I can use to design applications on the application diagram, and Figure 4 shows a sample application diagram.

Table 2. Application Designer Elements

Figure 4. Application diagram (Click on the image for a larger picture)

Similar to the Logical Datacenter Designer, you can add additional constraints and properties to your application definitions and endpoints, using the Settings and Constraints Editor. These constraints specify application requirements for deployment and constrain the logical server types to which an application can deploy. With the Application Designer, you can also define operations for Web services. For example, you can select a Web service provider endpoint on an ASP.NET Web application, and use the Web Service Details window to define the methods and parameters that define the Web service interface.

Most of the supplied application types support implementation and synchronization with code. When you right-click an application, such as a Windows Application or an ASP.NET Web Application, or right-click the application diagram and click Implement Application or Implement All Applications, Visual Studio creates projects for the selected applications according to their types and specified language, which can be either Microsoft Visual Basic, Microsoft Visual C#, or Microsoft Visual J#. If the applications were connected on the diagram, it even hooks up your applications, creating Web references and populating the required configuration entries. If your solution already exists, or if you just prefer to define the applications directly in code, simply adding the application diagram to a solution will cause the diagram to be reverse-engineered from your project, code, and configuration files. Once you have an application diagram in a solution with projects and code, Visual Studio keeps the diagram and SDM models in sync with your project, code, and configuration files silently and continuously in the background as you change either the diagrams or code.

System Designer

You can use the System Designer to design application systems, which are "units of deployment" that are composed from applications defined in the application diagram or from systems defined on other system diagrams, as shown in Figure 5. Since a system is a custom configuration of the applications, you can override individual applications from the default values you gave them, or include one or more uses of the same application definition or system definition in a system. As shown in Figure 5, each application can be connected and configured differently from its definition and as appropriate for how you want it to deploy. For example, you can override settings on an application that are designated as overridable on its definition. In fact, you can create multiple system definitions in the same solution, with each system representing an individual deployment configuration or datacenter configuration. This is useful for supporting many customers, each with different datacenters, running the same solution. To create a system, you can select the applications you want on the application diagram, right-click the application diagram, and click Design Application System.

Figure 5. System diagram (Click on the image for a larger picture)

Deployment Designer

Deployment Designer allows you to map your system designs to a logical datacenter diagram that was created with Logical Datacenter Designer, so that you can describe logical deployments for those systems. The Deployment Designer ensures that you map the right type of application to the correct type of logical server, also honoring any application hosting constraints that you may have set on the logical server in the logical datacenter diagram. Once all the applications in the system have been mapped, you can perform additional diagram validation, where Visual Studio checks all of the constraints and settings configured in Application Designer or System Designer against the logical datacenter design, to help catch any problems with configuration even before you've written a line of code. Validation errors appear in Visual Studio, similar to compiler errors and warnings. Double-click any of these errors, and Visual Studio takes you either to the application diagram or the logical datacenter diagram, selects the offending application or logical server, and opens the configuration setting that caused the issue. Once you have implemented your application and changed a setting, the change you make is instantly pushed into the configuration file—so the validation is directly providing information back into your development process.

This is like crash testing a vehicle before you've even built it! You can use this model validation to ensure that your application always meets the policies of your datacenter, and to understand the impact of change (either from the application architecture or data center perspective) throughout the solution's life cycle.

Team System for Software Developers

Visual Studio is already an amazing tool for writing code. Team Developer simply makes it better by giving developers even more tools to write higher-quality code, providing tools for the developer to perform code analysis against the code base, dynamic analysis against running executables for the purpose of collecting performance profiling and code coverage information, as well as a fully integrated unit testing framework.

Code Analysis

The code analysis tools provided with Visual Studio Team System analyze code while it's being built, and are based on time-tested tools such as FxCop and PreFast. These tools have the ability to analyze code for specific defect patterns that match rules specified by the user. To enable code analysis for managed code (written in any .NET Language), you can navigate to the Properties dialog box of any managed code project, click the Code Analysis tab, and select Enable Code Analysis, as shown in Figure 6.

Figure 6. Enabling code analysis

As you can see, there are dozens of rules that are already defined and enabled for you—from rules that check coding and design guidelines, to rules that check for security issues. You can choose to disable rules that don't apply to your project, as well as create your own rules to look for specific code patterns. When a rule detects a problem with your code, Visual Studio will throw either a warning or an error, depending on how you have configured the rule.

The code analysis tools can also be used to improve the quality of native Microsoft C++ code. For example, these tools can be used to help you identify buffer overruns, un-initialized memory, and null pointer dereferencing. These are reported in the same fashion as compiler warnings, which you can turn off using the #pragma compiler directive.

Dynamic Analysis

The dynamic code analysis toolset includes a code profiler to measure the performance of applications at runtime. There are two profiling modes: sampling and instrumentation.

Sampling peeks in and takes "samples" of your application performance every so often, to find out what it's doing. This form of analysis makes it less likely that the act of profiling itself will affect the performance of your application, because it is only running a small percentage of the time. Due to the statistical nature of the approach, however, it doesn't provide an exact representation of application timing.

Instrumentation, on the other hand, provides a thorough account of what your application is doing, because before your application is executed, the profiler will instrument extra code into every single procedure and method call, allowing it to track exactly what method was called and how long the method took to execute. Instrumentation-based profiling will slow down the performance of your application, simply because there are more lines of code running and more data being collected, as shown in Figure 7.

Figure 7. Results of instrumentation profiling (Click on the image for a larger picture)

Unit Testing

Unit testing has always been an important part of the software development process. Unit testing refers to a specific type of testing responsible for validating one aspect of the system—a specific function or procedure, a component, or even a usage scenario. Team System provides a framework for writing and executing unit tests in both Team Developer and Team Test, and provides tight integration into the development IDE. As shown in Code Sample 1, unit tests are attributed test functions that verify the behavior of a corresponding function or procedure in the product under test. Once you add the [TestMethod] attribute to your test code, Visual Studio will recognize it as a unit test and display the function in the Test Manager windows, as shown in Figure 8.

[TestMethod()]
public void AdditionTest()
{
Math target = new Math();

int x = 5; 

int y = 5; 

int expected = 10;
int actual;

actual = target.Addition(x, y);
Assert.AreEqual(expected, actual, 
  "Math.Addition did not return the expected value.");

}

Code Sample 1. Simple unit test

Figure 8. Managing tests in Visual Studio (Click on the image for a larger picture)

Test Manager will allow you to select and execute your unit tests, as well as group, filter, and organize them into Test Lists. Each test managed through the Test Manager can have a set of work items associated with it, as well as other pieces of metadata, including Priority, Owner, and Class Name.

Code Coverage

Wouldn't it be great to get some indication of the amount of code that was actually exercised during the execution of a unit test? Well, this type of analysis is called code coverage. Team Developer and Team Test both provide you with the ability to execute your unit tests and to track which lines of code executed during those tests. These results will indicate what other unit tests may be required in order to ensure that all lines of code are tested, as well as to give you a good idea of how complete your testing practices are. Figure 9 and Figure 10 demonstrate the results of code coverage analysis. In Figure 9, the lines of code highlighted in green represent lines that were executed during the run of the unit test, whereas the lines in red indicate code that was not executed at all.

Figure 9. Code coverage results in Code window

Figure 10. Code coverage statistics (Click on the image for a larger picture)

Team System for Software Testers

I remember when I was in university and one of my professors told me that if I work really, really hard, one day I could even be a software tester. Yet with the challenges of today's need to write business solutions faster than ever before, there is often a temptation to skimp on software quality assurance. Furthermore, those organizations that embrace testing on their software development projects often don't have a very good selection of integrated tools to support their testing needs, being forced to purchase very expensive and not well integrated software testing solutions. Microsoft has addressed these challenges by providing a set of integrated testing tools for both developers and testers alike.

We've already seen how Developers are provided with an integrated unit test framework. Well, Team Test takes this one step further by providing even more testing capabilities and a management console to help manage, execute, and track tests. Table 3 provides a list of tests that can be created, managed, and executed with Team Test.

Table 3. Team System Test Types

Team Foundation Server

Team Foundation Server perhaps provides the most significant set of features provided by Team System. Team Foundation helps to facilitate the entire team by providing a new source control management system, work item tracking capabilities, build automation, integrated analysis and reporting, and an integrated collaborative project site; it also provides project management capabilities with the integration of Microsoft Project and Microsoft Excel 2003.

Source Control Management

Microsoft Visual SourceSafe (VSS) is one of the most common source code control systems for Microsoft developers, and has played a large and important role for software developers over the years. VSS, however, wasn't known for its scalability, stability, robustness, or the ability to work well across time zones and over the Internet. Visual Studio Team Foundation now ships with a brand-new source control engine that resolves all of these problems. Team Foundation's source control server components utilize Microsoft SQL Server 2005, and is a well architected and scalable source control solution that works well over HTTP and HTTPS, and that supports other features, such as time zone awareness, that will help you facilitate diverse multi-geographic development such as is required with offshore development teams. Team Foundation's source control solution also plays an important role in the process of software development, by supporting check-in policies, which are rules that govern the check-in process. For example, you can require developers to associate a check-in with at least one work item prior to the check-in process, helping to establish traceability between work items and the actual development work completed. You can also create check-in policies requiring that code analysis be run, or even that all unit tests be executed prior to the check-in action. If a developer needs to override these policies, a notification e-mail message can be automatically sent to relevant team members, explaining the exception. Figure 11 and Figure 12 demonstrate how check-in policies and check-in notes can be controlled by project administrators.

Figure 11. Adding check-in policies

Figure 12. Adding check-in notes

Another important feature of Team Foundation's source control is shelving. Shelving allows you to place your checked out code in a "shelveset" located on the server, where it is maintained until you are ready to take it off the shelf. Essentially, this allows you to store work-in-progress code on a "shelf" in the server, without overwriting or corrupting existing code in the live tree. This is handy if you need to use multiple computers, transfer partially completed work to another developer, or to quickly switch to working on a high-priority issue and so need to move your current changes out of the way

Work Item Tracking

As mentioned before, a work item is a "thing" that can be assigned and completed by someone on your team. At its simplest level, it could be a simple task with a simple state transition, such as "opened" and "closed." However, most projects have different types of work items, each with its own characteristics and workflow states and transitions. Other examples of work items could include bugs, issues, risks, or even features. All work items, regardless of their type, are stored in Team System. When you create a new project, the definition of the project will also determine the number and type of work items that you will be able to create. Each work item type can have its own states and transitions, and generally speaking, each work item can be assigned to someone, providing information such as target iteration or release, priority, and so on. Work items can also link to other work items, files in source control, and even a changeset within source control. Being able to link work items together, and between different things such as files and source code, provides the traceability needed on almost all software development projects. Don't worry, this is a very extensible model, and you can make changes, as needed, to support your specific project needs.

Figure 13. Example of using work items for traceability

Team System provides a collection of work items, and you can interact with them using many different tools—from Microsoft Project, Microsoft Excel, and Visual Studio, to Team Explorer—as shown in Figure 14 and Figure 15.

Figure 14. Work item definition in Visual Studio (Click on the image for a larger picture)

Figure 15. Work items in Excel (Click on the image for a larger picture)

Build Automation

Build automation is an extremely important best practice for software development teams. Team System provides build automation with Team Foundation Build, which leverages MSBuild, can run associated unit tests and code analysis, release builds to a file server, and publish build reports to the rest of the team. Team Foundation Build results and logs can be propagated to the Team System data warehouse for reporting and analysis. Additionally, Team Foundation Build is fully integrated with other Team System tools such as source control and work item tracking.

With Team System, you can have many different build types that you can define and customize for your own needs. In fact, Team System provides a wizard to get you started, as shown in Figure 16.

Figure 16. Defining a new build type

The results of all builds are maintained, and can be viewed from within Visual Studio or through build reports. It is also important to note that you can set up many build machines to actually perform the build process, and you can kick off the build process through the GUI or through the command line. Additionally, you can configure Team System to notify you of the results of a build by e-mail, as shown in Figure 17.

Figure 17. Configuring alerts for build events

Reporting

Wouldn't it be great if you could automatically generate a report that depicts how fast your team is working from week to week, based on their actual activities? Well, guess what? With the reporting features of Team Foundation, you will have this ability. Team Foundation is built on SQL Server 2005, and it stores everything about work items, quality attributes, testing and test results, as well as build results. All of this information is aggregated with SQL Server Analysis Services and tied to the reporting features of Team System. In fact, the reports that Team System provides are created with SQL 2005 Reporting Services; meaning that you will have the ability to modify the existing reports, and even create your own to best suit your needs.

Dozens of reports will be shipped with Team System (a sample report is depicted in Figure 18), because they are part of the Team System Project Templates used during the creation of new Team System Projects. As you customize Team System Project Templates to create your own work item types, or modify existing work item definitions, you will likely want to customize the default reports.

Figure 18. Sample report (Click on the image for a larger picture)

Project Site

When you create a new Team System project, you are prompted to create a new Microsoft Windows Sharepoint Site to further enhance collaboration for the project. Microsoft Windows Sharepoint Services provides the document management and storage capabilities for documentation created by the team for the project. The definition of the Team System project template also defines the structure and content of the Sharepoint site, right down to document library structure and document templates. In fact, you can configure Team System to create a Project Portal site that contains all of the artifacts that need to be filled out as part of your project, making it easier to ensure that the correct artifact is delivered at the right time.

The Windows Sharepoint site will also contain Web parts that allow you to view reports right on the site. This is a very important feature, because now non-developer project stakeholders without Visual Studio can go to one place to understand the health, status, and details of your project, straight from their browser.

Figure 19. Project site (Click on the image for a larger picture)

Project Management

Project managers typically use either Microsoft Project or Microsoft Excel to manage "stuff" that needs to get done. In the world of Team System, this translates into being able to manage work items of various types across your team. Visual Studio Team System provides a built-in interface to allow project managers to interact with work items. However, in many cases, it's much more natural to have project managers use the tools they most commonly use to do their jobs. For this reason, Team System allows you to synchronize work items with Microsoft Excel and Microsoft Project. In these tools, project managers are free to assign and track all work items (regardless of type) in a natural and productive manner.

Reports are also extremely important to project managers. With Team System, project managers will be able to use the dozens of built-in reports that ship with the product, as well as to use analysis tools such as Microsoft Excel to connect to the Team System data warehouse in order to analyze project data. Project managers can also use the features of the Windows Sharepoint site created for each Team System project, to facilitate communication and manage all project documents and artifacts.

Team System Extensibility and Customization

As mentioned before, Team System is not just a set of tools: it's a platform. I don't really want to spend a great deal of time discussing extensibility, aside from listing the areas that Team System can be extended. The following table provides an overview of these options.

Table 4. Team System Extensibility Summary

Conclusion

Obviously, Team System is new and provides a powerfully diverse set of tools to support virtually all aspects of the software development lifecycle. What might not be as obvious is how to adopt Team System into your organization. What should be clear is that simply adopting a set of tools won't necessarily solve all of your problems. The features provided by Team System should fit into a much broader vision of software development processes within your specific environment. Team System should be used in a way that best fits the unique needs of your organization, and not the other way around.

This article wasn't really intended to go deep on any one particular feature, but instead to provide you with a high-level understanding of how the pieces of Team System fit together. I encourage you to dive more deeply into the areas of Team System that most interest you, and to start taking the time to understand how this integrated, yet extensible, tool suite will help your software development teams be more productive and predictable.

As you learn more about Visual Studio Team System, there are several blogs that may be of interest. For starters, check out: https://blogs.msdn.com/askburton.

© Microsoft Corporation. All rights reserved.