VSTS Whys and Hows Part II

In the first article in this series I described some of the problems inherent in modern software development and suggested a few ways in which those issues might be addressed by tools like Visual Studio 2005 Team System (VSTS) soon to be released. In other words, the first article addressed the “whys” of VSTS. In this article I’ll tread further on that path by providing an overview of Visual Studio 2005 Team System (VSTS) from a functional perspective so that you can see how VSTS plans to address the problems.

More than the Sum of Its Parts
From a high level, VSTS is composed of five products:

Visual Studio Team Foundation. This is a server product or platform that exposes features shared by the various clients (as well as Office applications such as Microsoft Excel and Microsoft Project) shown in the diagram. While some of the features exposed by the clients can be used independently, it is Team Foundation that pulls them all together and enables the collaboration and communication so desperately needed by software development teams.

Visual Studio Team Foundation Client. A client tool geared towards project managers and other non-developers. The Team Foundation Client exposes a subset of the shared features in Team Foundation through the concept of the Team Explorer discussed below. While the Team Foundation Client is based on the Visual Studio IDE it does not include the language features and other tools that developers and architects would use. The Team Foundation Client is the basis for integration in the other products mentioned here.

Visual Studio Team Architect. The client tool used by software architects to design serviced-oriented solutions and validate their designs against the actual hardware and software environment. Team Architect also includes a modeling tool called the Class Designer that is tightly integrated with code.

Visual Studio Team Developer. The traditional Visual Studio IDE augmented with a set of features that enable developers to more easily comply with policies and collaborate in a team environment. Although many of the features found in Team Developer such as unit testing and static code analysis can be used without access to Team Foundation in the Visual Studio IDE, the metrics or results that the tools output cannot then be shared with the team.

Visual Studio Team Test. A client tool for those devoted to testing that enables them to design, manage, and execute manual, unit and load tests.
Each of these products is designed to provide specific features that aid in the process of software development. It is their combined power when adopted by the entire team, however, that allows VSTS to address the core issues teams face of communication, predictability, integration, and process. In the remainder of this article I’ll drill down on each one of the products and walk through its key features so you’ll understand how it fits into the bigger picture.

Visual Studio Team Foundation
As we saw in the first article, many of the problems encountered by software development teams arise from lack of communication within the team and lack of integration of the tools used by the team. In VSTS the Team Foundation provides the server platform that enables both communication and integration. In that way Team Foundation can be thought of as the organizing principal in VSTS. And because of its centrality it is worth having a look at its major features.

Change Management. A brand new (not simply a new version of Visual SourceSafe) source code control infrastructure based on SQL Server 2005 for versioning code and other project deliverables. Built from the ground up for secure and high-speed access, this is a robust version control system that supports advanced features such as branching, change sets, a novel feature called shelving, as well as check-in policies. To give one example of how this feature addresses the problem of integration discussed in the previous article, consider VSTS’s check-in policies. Essentially, when the Project Manager creates the project in VSTS he can associate policies with the check-in of source code. These policies validate that a developer’s changes comply with whatever the organizational requirements are before the set of changes can be checked-in. For example, a check-in policy might be activated so that a developer must run static code analysis or a unit test on his code before checking it in. If the developer fails to do this he’ll receive a policy warning in the Team Developer IDE. If he chooses to ignore the policy the project administrator can optionally be notified through email.

Work Item Tracking. A centralized repository stored in Team Foundation’s SQL Server 2005 operational data store and used to track tasks, defects, requirements, enhancements and - through the use of custom attributes - anything else required by the project. If Team Foundation is the organizing principal in VSTS, then Work Item Tracking is the central concept within Team Foundation. Requirements, unit tests, test cases, and source code can all be associated with work items to provide the basis for a rich set of metrics collected by the client tools. And as with other aspects of Team Foundation, a set of default Work Item types ships with the product but can be extended by your organization or third parties. Project managers and other team members can interact with work items through Visual Studio Team Foundation Client or even Microsoft Excel and Microsoft Project. Of course, correlating this information with the detailed data collected by the various tools makes for a powerful combination in terms of reporting on the health, status, and direction of the project.

Reporting. A set of over thirty predefined reports built with SQL Reporting Services used to report on the health and status of the project. These reports can then be made available both on the Team Project Portal and directly within the applications used by the team members through the Team Explorer. Data to produce these metrics is actually collected behind the scenes by the tool in which the team members work as they perform their tasks and then stored in a central SQL Server Analysis Server repository from which the reports are created. For example, data about test execution and results are saved when a tester executes his test cases and data concerning code churn is saved when developers check out and check in code files. This approach has the obvious advantage of freeing Project Managers and other team members from the hassle of data collection and ensures that the data is always fresh. At the same time the data collection process is not intrusive and works within the natural workflow of the team.

Team Project Portal. To help solve the problems related to collaboration and communication Team Foundation automatically creates a web site or Team Project Portal for each project using a Windows SharePoint Services (WSS) team site. From this portal project stakeholders can get a quick view of the project’s progress both freeing up the time project managers would spend creating status reports by hand and enabling stakeholders to provide input and make course corrections. The portal’s document library is also pre-populated with document templates, for example discovery and requirements specification templates, and sample files for use by team members.

Project Management. We saw in the first article that teams could benefit from tools that help guide them through the process of software development. In order to provide process guidance VSTS includes the concept of methodology templates which can be thought of as a schema for software project. These templates help to structure the process used by the team by exposing a set of documents, project roles, work item types, a web portal template, policies, and what are called process tasks from within all of the VSTS tools. For teams that have no process a Project Manager can choose one of the predefined methodology templates that will ship with VSTS such as a new version of Microsoft’s Solution Framework called MSFT Agile.

Build. One of the required activities in a software development project is to actually build the software. To that end a core feature of VSTS exposes a common process for building executables based on the tool Microsoft uses internally called MSBuild. This system is designed to deliver a “build lab in a box” that makes it easier for teams to implement the best practice of daily builds. This tool allows for the creation and execution of automatic builds on a separate build server that integrate different types of tests. As the tests execute data is collected about the builds in the operational and analytical data stores, for example to tie the build number to Work Items and automatically create work items for build failures.
Taken as a whole these features provide a solid platform on which teams can define and implement their software development process.

Team Foundation Client
The second product that comprises VSTS is the Team Foundation Client. This can be thought of as a tool that Project Managers and other generally non-technical team members will use. While it runs within the Visual Studio shell, it does not include the overhead of language compilers and modeling features that PMs and other don’t need nor want.

The services of Team Foundation are exposed in the Team Foundation Client through the Team Explorer. This tool is accessible within all of the different VSTS clients and really provides the foundational access to VSTS.

The Team Explorer is a tool window that can be hidden similar to the Server Explorer that developers are already familiar with in previous versions of Visual Studio .NET. Through this window team members can easily find work products and data associated with the project

More importantly the Team Explorer also acts as a launch point into the set of tools that ship with VSTS. By simply navigating to the appropriate node in the Explorer the context of the application changes and allows the team member to create and run reports, query on tasks assigned to them, create custom queries, and view project builds and test results among other activities. No longer is there a need to manually switch between various tools thereby increasing productivity.

Team Architect
In the previous article I discussed the scenario where a Solution Architect creates a design only to find out later that it is precluded by the hardware or software configuration of the deployment environment. In order to address these sorts of issues the Team Architect product, in addition to including the Visio UML modeling tools present in the prior version of Visual Studio Enterprise Architect, includes a suite of graphical modeling tools. These tools are designed to allow architects to visually design systems based on service oriented architectures (SOA) and to validate those designs against the actual environments in which they’ll run.
Specifically, the suite of tools includes:

Application Designer. The Application Designer provides a design surface on which the architect can diagram a set of applications that exchange messages. In other words the Application Designer can be used to create a model of connected applications that are dropped on the design surface and connected via Web Services Description Language (WSDL) contracts. Off the shelf application types include web sites, Windows applications, web services, databases, and BizTalk services as you can see in the toolbox on the left side of the screen.

Logical Data Center Designer. The Logical Data Center Designer is a designer that an Infrastructure Architect can use to create a logical model of a part of the data center. As such it allows for the creation of “logical servers” that specify the application hosting environment on those servers. For example, a logical server can specify the communications protocols allowed (perhaps on HTTPS) and the types of services that are enabled (IIS, FTP) in addition to the communication between other logical servers and those servers grouped into what are called “zones”. Constraints including security requirements on the logical server can then be specified. The architect can either create the servers himself or read the configuration information from physical machines using the tool.

System Designer. The System Designer provides a design surface used by the architect to create what is referred to as a configured system. A configured system is composed of one or more applications defined in the Application Designer for a particular deployment. The System Designer provides a higher-level view so that architects can visualize how systems will communicate with external systems or with other internal (nested) systems. From there the architect can drill down to the applications if necessary in order to define them.

Deployment Designer. The Deployment Designer is used by architects to create a deployment for a configured system defined in the System Designer or for an application defined in the Application Designer. Here is where the application and systems models are mapped onto the data center models through a process called binding. Prior to this all the information (metadata) collected by the designers was made available to a constraint engine and as a result validation and consistency checks can be made. If the configuration of an application violates constraints on a logical server, the Task List within Team Architect alerts the architect to the issue, thereby allowing the problem to be corrected before actually attempting a deployment. The Deployment Designer also generates a deployment report visible that can be used to communicate between IT and Operations as well as a deployment script that includes configuration settings and files to be deployed.

Class Designer. Although not directly connected to the other three tools, the Class Designer provides the architect with a superset of the capabilities of traditional UML static structure or class diagrams. The Class Designer represents the .NET type system with full fidelity and therefore allows architects to be very precise in the design of their classes, structures, enumerations, and interfaces in a way that UML cannot. Indeed, as types are designed on the surface of the Class Designer the code for those types is written in the project. Conversely, changes to the code will be reflected in the model since both the code and model are simply reflections of the SDM. And because design at this level isn’t restricted to architects, the Class Designer is also available in the Team Developer. Obviously, this more connected approach can help to solve some of the communication problems inherent in software development.

Team Developer
In many teams today, however, developers are hindered from reaching high levels of productivity by having to cobble together multiple tools in order to adopt development best practices and having to repeatedly context-switch between tools in order to interact with requirements and tasks. When multiplied across all the developers on the team, this in turn drives down the predictability of the entire project. To address problems like these Team Developer includes the Team Explorer mentioned previously. This tool window immediately gives the developer the ability to see which Work Items (tasks) they are responsible for and through its integration with Team Foundation can tie actual work the developer is doing to those work items thereby automatically and continuously updating the project’s status. As you would expect Team Developer integrates with Team Foundation by providing the interface to Team Foundation’s change management (source code control) system and its’ check-in policies discussed previously.

Team Developer also includes the following tools.

Unit Testing and Code Coverage Analysis. One of the best practices that Team Developer enables is unit testing and by extension the practice adopted by many agile teams known as Test Driven Development or TDD. Team Developer does this through its inclusion of an attribute-based unit testing framework much like the popular NUnit that is directly accessible within the IDE. Using this framework developers can create unit tests and execute them during the development process while behind the scenes the results are automatically recorded in Team Foundation’s analytical data store. In addition Team Developer enhances its power by coupling it with the testing best practice of code coverage analysis. Using this practice, when a team member executes a unit test not only will the test results be tabulated but optionally the percentage of code executed during the test for each source code module (files, namespaces, classes, methods) can be viewed as well as being stored by Team Foundation for later use.

Static and Dynamic Code Analyzers. A second best practice that teams often have a harder time getting their developers to adopt is code reviews. When done well, code reviews with other developers and architects provide a structured way to gain feedback in a constructive way that proactively enables the developers to make changes that improve code quality and maintainability. To address this need Team Developer includes both Static and Dynamic Code Analyzers that can be thought of as an automated method of performing code reviews. For example, the static code analysis tool comes preconfigured with a set of warnings that can identify known issues in .NET development involving performance, security, general design, and naming guidelines akin to the FxCop tool in use by many in the .NET developer community.

Code Profiler. Developers can also increase their productivity through proactively addressing performance problems using tools Team Developer includes. With these tools developers can sample the performance and then instrument their code in order to collect detailed performance statistics to enable drill down on potential problem areas. For example, a developer can use their unit tests to generate a Performance Session where the code is sampled in order to identify potential performance bottlenecks in terms of both throughput and resource usage. From there the developer can instruct the tool to insert timing probes into the desired subset of code to gather more detailed statistics. Finally, a detailed performance report is generated so that developers can decide where to begin further investigation.

Team Test
VSTS takes testing a step further than simple unit testing by making them available in the Team Test product geared specifically for testers. This product enables testers to execute the unit tests developers create in a systematic fashion to ensure that code checked in by multiple developers passes previously constructed tests. This is an example of another testing best practice referred to as regression testing.

Team Test goes even further by making testers first-class citizens of the project by highlighting the importance of testing at the team level through a test authoring and execution environment. That environment includes additional test types such as Web Tests, Load Tests (similar to the tool Application Center Test tool that ships with Visual Studio .NET 2003), Manual Tests, and Ordered Tests and test case management all integrated into Team Foundation.