In-Depth
Delve Into Visual Studio Team System
Visual Studio Team System provides a wealth of tools in one place. Explore all aspects of this integrated suite of tools.
Visual Studio Team System (VSTS) is a suite of tools designed to allow a development team to communicate not only with one another, but also with stakeholders, in real time. It also contains a set of tools for developing architectural views of a system, generating code from certain views, testing code at all stages (during and after development), and integrating the testing experience with project management. At a high-level view, VSTS is divided into four areas: integration, architecture, development, and testing. Each of these areas contains tools that cater to a different facet of the development team. Some of the tools are available to all groups of users, and some are targeted at a specific group associated with only one role.
Team System is also designed, from the ground up, to help an organization implement an effective development methodology, whether it's Microsoft Solutions Framework (MSF), Rational Unified Process (RUP), Extreme Programming (XP), or any of a dozen other types. The purpose in implementing a structured methodology is the same as the goal of the rest of the VSTS suite of tools—to build better applications for a lower cost both in the short term and the long term. This concept of integrating methodology into the development process is ingrained in all aspects of Team System.
VSTS comes in three different editions (Team Edition for Software Architects, Team Edition for Software Developers, and Team Edition for Software Testers) and a core component called Team Foundation. Team System features out-of-the-box functionality, but it is also highly extensible. Joining the Microsoft Visual Studio Industry Partner (VSIP) program allows you access to the VSTS APIs, letting you integrate virtually any tools you have into the VS IDE.
Team Foundation is the server-based component of VSTS. It is the "team" in Team System. Without Team Foundation, all of the other components of VSTS are essentially standalone components that run on the client. Once Team Foundation becomes part of the picture, the various client pieces start to work together as a cohesive unit.
Team System provides a framework in which applications can be built. Many companies these days are working to improve their processes by using the Capability Maturity Model Integration (CMMI) from Carnegie Mellon's Software Engineering Institute (SEI). Microsoft, with Visual Studio Team System, is releasing the only methodology recognized by SEI as being CMMI level 3 compliant. This methodology is the Microsoft Solutions Framework (MSF) version 4. The template and instructions on how to use the methodology are all included with Team System. You might ask, "What is so significant about this?" In order for a company to provide software to the U.S. government, the software must, at a minimum, be CMMI level 3 certified.
Team Foundation
Team Foundation contains a Source Code Control tool that is backed by SQL Server 2005 and designed for large-scale teams. It is a welcome edition to the developer's toolbox and allows an easy alternative to Visual SourceSafe. It also supports project managers and overall application reporting to the stakeholders. You can also use this tool to implement policies to ensure that code meets certain requirements before it is checked in. This ensures that the code base is always stable.
Another key piece of Team Foundation is the project site. This SharePoint Services site serves as a central communication tool for the entire team. Stakeholders can go to this Web site to review the current status of various tasks on the project, view nightly build and test reports, and have discussions or ask questions of the team. SharePoint also serves as a project-documentation repository (with version control).
Team Build is a component of the foundation that allows a server or workstation to become a build machine. Team Build automatically gets the latest version from Team Source Code Control (or a specific version), compiles it, deploys it, and runs any automated tests (unit or Web tests) against the build. The results of the compilation and testing are stored in the Team System data repository.
Work Item Tracking is another feature of Team Foundation in which you can create work items in Microsoft Project (directly from the WBS) or Microsoft Excel and load them into Team Foundation. These work items can be assigned to developers who, when checking their items into the source code control, can associate changes (or bugs) against specific work items. The status of these work items is then reflected on the project portal. Work item association can be enforced via policies as well.
The final feature of Team Foundation is the reporting component. A team's project reporting is backed by the new version of SQL Reporting Services. Out of the box, the reports cover areas such as number of open bugs/closed bugs/in-work bugs, work item status, build results, and so on. As an added bonus, SQL Reporting Services features an end-user ad-hoc report builder so users can create their own reports or customize existing reports. This, combined with the Team System data repository, allows an organization to mine the data for trends in the overall software development lifecycle.
Team Architect
Various types of architects, each with different responsibilities, can work on a single project. The one thing that all architects have in common is that they must communicate aspects of the architecture to various stakeholders in various ways. It is in this spirit of building and then communicating an architecture that Microsoft provides the designers in the Team Architect Edition. VSTS provides four designers: Logical Datacenter Designer, Deployment Designer, System Designer, and Application Designer.
These designers are a core tenet of Microsoft's focus on Model Driven Architecture. However, VSTS moves models out of the cumbersome, documentation-only realm and into the practical realm. The problem with modeling with other tools is that the models are abstract representations of the architecture. They do not mean anything. The designers in VSTS have a concrete implementation. When you create a model with VSTS, you also generate the configuration for that model, which is based upon physical properties of the object you're deploying your application to. This allows VSTS to check for inconsistencies in your architecture against a representation of the actual physical machines you will be working with.
On top of this approach, VSTS introduces a new concept called a "domain-specific language," which is the "language" in which the concrete implementation of hardware or software is written. This allows the end users of VSTS to build model objects against which specific implementations can be validated. Microsoft has released a set of tools specifically for creating domain-specific frameworks (more here). The language is a set of metadata that describes the physical implementation of a given configuration. These designers are built in concrete terms, so their intended audience (whether data architects or infrastructure architects or other application architects) understands them easily.
Team Architect also includes everyone's favorite modeling tool, Visio. This tool is available in all editions of VSTS, but will probably be most used by architects. Visio for Visual Studio allows for the creation of UML diagrams and provides the ability to model different views for different audiences of the application. Visio allows you to create those abstract, notional views that are helpful in trying to figure out and pinpoint what the architecture will be and then communicate it to everyone else.
Team Developer
The Developer Edition of VSTS provides tools that allow developers to understand code faster, generate code from models, write unit tests, and analyze code for errors. The goal of these tools is to reduce the amount of time developers need to actually write code and to ensure that the code that is produced is of a higher quality than they might be turning out currently.
The Class Designer is available in all editions of VSTS because it is useful to a wide range of people. Architects can use the tool to create high-level class designs. Developers can fill in the diagrams in order to generate skeleton classes that they can then fill in the details for. And testers can use the Class Designer to understand the relationship between classes in order to help them analyze errors.
The Class Designer also generates code dynamically based on the model, reads changes in code, and incorporates those changes into the model. The key point here is that the model and the code are never out of sync. This solves the problem of documentation becoming stale.
Once the general outline of code is written, tests can be written for the code. They can also be written after the code is finished. It is entirely up to you, but one thing is certain—the unit-testing component of VSTS will make the process a lot easier, faster, and more streamlined.
Creating a unit test is as easy as right-clicking on a class and method, selecting Create Tests, and filling in a couple of variables. It could also be more complicated, because unit testing supports data-driven testing, which allows for powerful testing capabilities without having to rewrite the unit tests continually or write many tests for one method. The unit-testing functionality is also part of the Team Test edition.
As part of the unit-testing functionality, VSTS also provides a cool code-coverage tool. This tool not only tells you what percentage of your code was covered vs. not covered, but it will show you as well.
The code can actually be highlighted to show you fully covered lines of code, partially covered lines of code, and code that is not covered at all. To give you an idea of how important this tool is, take the following example. You write a method 100 lines long, and you run the unit tests against the code. The results all come back as passing, which is good, but the code covered is indicated at 60 percent, which is bad because 40 lines of code were never touched. This indicates that while all your tests passed, you either did not test something you should have or there is no way to test that code and so it is dead code that should be removed.
Since the inception of .NET 1.0, Microsoft has had a relatively unsupported tool called FxCop that is available for free from www.gotdotnet.com. VSTS incorporates this tool into the IDE so that code analysis on managed code can be performed as part of a compilation and policies can be written against the results of the analysis. This tool was created originally to ensure that Microsoft developers were following the correct standards when writing the .NET Framework. If you follow the coding recommendations of this tool, you will be writing to the same standards as Microsoft (in terms of format, completeness, and the standards of the .NET Framework).
VSTS also incorporates a Performance Analysis tool that allows developers to test their code for bottlenecks. In the past, typical performance testing around a .NET application involved monitoring a lot of Windows Performance Monitor logs, which provided less-than-helpful information. The new performance tool allows you to either instrument or sample your code depending on the situation so you can gather detail at the individual method level or at the application level. Best of all, you can institute performance monitoring on a production application to pinpoint specific problems that might not have been apparent during development.
Finally, VSTS incorporates a tool to help developers of unmanaged code. This tool, called "PREfast," has been in use within Microsoft for several years as a means to check C/C++ code for common errors such as buffer overruns. Microsoft has "productized" it for inclusion in VSTS. You can run this analysis tool simply by checking a box in the project properties. It is customizable to the extent that it allows you to implement checks not included in the out-of-the-box product.
Team Test
The final component of Visual Studio Team System is the Test Edition. This edition is devoted to testing all aspects of the code. It includes the unit-testing functionality (described in the Team Developer section), load testing, manual testing, Web testing, and test management.
Test management is a key component of the testing infrastructure because it allows you to organize your tests. You can run tests in a non-interactive fashion from the command line or from the Team Build process. You can organize tests into lists in order to run them on like processes. Dependencies can be created between tests via an Ordered Test List, and individual tests or lists of tests can be slated to run at any given time. The Team Developer edition includes a cut-down version of this test management tool.
More and more applications are moving to the Web in today's Internet- and intranet-based world. Because of this, Microsoft rewrote the Application Center Test (ACT) Web-testing tool and included it with VSTS. It is a completely different tool and far, far more powerful than ACT was. You can record tests interactively and play back tests that are displayed visually for you as the test is running.
You can change the tests in the IDE and convert them to coded tests, allowing you the freedom to do virtually anything in a test you want through managed code instead of scripting, which had to be done with ACT. All of the information about a test is recorded. If you want to record something additional, you can code a custom extraction rule. You can also validate a result in the page and take an action based on the result. The tests can also be run with results supplied from a database. This means that the testing can include dynamic navigation of a Web site. You can add think times to each step of the test to simulate real-world browsing of a Web site.
The Test Edition also features manual testing, which allows you to run tests that are based of off a list of steps. The pass/fail status of these tests is recorded just as any additional test is, and code coverage (if enabled) is captured for these tests as well. You can write the steps for these tests in Microsoft Word or in a plain text file in any format your organization uses.
Finally, load testing is designed to see how your application (both hardware and software) performs in a real-world load simulation. You can set the type of browser that is accessing the site, the type of network connection the browser is using to access the site, the way in which the think times are simulated (set times or a normal distribution), and which tests are actually run as load tests and their distribution. You can also set ramp-up times, or the tests can be run at a constant user load.
The tests can be run from the local machine, which simulates all of the connections, or they can be run via agents and a controller from many different machines. The controller directs the agents to run the test(s) and records the result in one location. A typical setup for this is a lab where you might have 20 test machines hitting one box with a Web site. This saves you the time and effort of starting the tests on all of the machines individually. Every aspect of the test is recorded from both the software and the hardware perspective, and errors are stored for later analysis. The entire test result is saved to the Visual Studio data repository (if you are working with the Team Foundation piece).
Visual Studio Team System provides a wealth of tools in one place. The tools work together to help you and your organization produce better quality code with less error in a shorter period of time. The hassle of using 10 different tools from six different vendors is over. And for those times when you want tools with additional features or you want to use a tried and true tool, you can always add them in via the open and extensible API.