CI Tools and Best Practices in the Cloud

Continuous Integration

Subscribe to Continuous Integration: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Continuous Integration: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Continuous Integration Authors: Stackify Blog, Aruna Ravichandran, Plutora Blog, Dalibor Siroky, PagerDuty Blog

Related Topics: Continuous Integration

Continuous Integration: Article

A Developer's Introduction to Visual Studio 2005 Team System

Simplifying developers' lives

Development in team situations introduces a significant amount of additional challenge and complexity. Today, most savvy teams have assembled a set of tools to complement the Visual Studio IDE when working in a team environment to address these challenges.

These toolsets generally include a source control system (Visual SourceSafe, Vault, CVS, or Subversion); a bug/issue tracking system (FogBugz, Bugzilla, or Excel Spreadsheet); a code analysis tool (FxCop); a unit testing harness and unit testing code coverage tool (NUnit and NCover); a command line build system (NAnt); and a build management system (CruiseControl.NET or Draco.NET). Although these toolsets are generally robust and effective, a significant amount of effort is required to get them setup properly and working together.

When Microsoft releases Visual Studio 2005 next year, it will include a new set of integrated tools that help in team development environments called Visual Studio Team System (codenamed Burton). These tools address the tasks mentioned here, but in a highly integrated fashion.

With Visual Studio Team System (see Figure 1), Microsoft is releasing tools that address the needs of the application architect, infrastructure architect, project manager, tester, and developer. This article focuses on developers and how Team System will simplify their lives.

Team Foundation is composed of a client and server component. The server stores information in Microsoft SQL Server 2005 and is enabled via Web services. It serves as the primary information store used across the entire team. Because it can leverage secure Web services, it can be used over the Internet securely fostering distributed team development.

A Central Repository
At the center of Team System is the server-based repository called Team Foundation that handles the data and services for the team. Team Foundation will require a separate server installation with Microsoft SQL Server 2005 and IIS for client connectivity.

Within Team Foundation is a new source-code control service that has been codenamed Hatteras. This is not the next version of Visual SourceSafe, but rather a completely new application (Visual SourceSafe is being upgraded also, but is more focused on smaller development groups). Hatteras has been built to support enterprise-class development with a focus on performance and scale. Again, because the data is stored within SQL Server rather than in a file-based store (e.g., Visual SourceSafe), there is inherently better reliability and integrity.

From the developer's perspective, there are a lot of similarities between Hatteras and Visual SourceSafe. There is tight integration within the Visual Studio IDE, and the primary user interface remains the Solution Explorer. Additionally, when items are moved, renamed, or deleted within the Solution Explorer, those changes are replicated to the central code repository. There is also a command line version of the client for developers who are more inclined to work within the command prompt or if they want to write batch files that include source control commands.

There is some new source control functionality in Team Foundation that makes it much more powerful than Visual SourceSafe including:

  • Support for CVS style development (edit/merge/check-in) in which multiple developers can work on the same item in the repository with a merge tool if there are conflicts on check-in. Code locking is also supported.
  • Shelving is a new feature in which developers can save their current changeset (one or more files containing changes that are related) in the repository without checking it in. This can be beneficial in situations in which developers need to fix a bug in their current code but don't want to merge in their current changes. It is also a great way for developers to back up their changes in the central repository to protect against local machine failure without actually checking in those changes.
  • Hatteras can enforce check-in policies such as requiring a comment or ensuring that static code analysis passes. These policies are configurable and can be set for specific installations.
The source control mechanism is tightly integrated with a work item tracking database. Work items are similar to the lists that most teams keep in Excel worksheets, such as issues or bugs, which are assigned to a member of the team. They are fully configurable and customizable.

When changesets are checked into source control, they can be associated with a work item so that there is a level of traceability for why code changed. For instance, a developer may want to create a certain type of work item for bugs that are discovered during a system test. A new work item type can be created that has different attributes (e.g., who discovered it, a description, a priority, and who currently owns the bug). As items are entered into this list, the owner can be notified. When changes to source are made, the developer relates them to the bug work item. In this fashion it is possible to know who changed the source and why.

Another benefit of having all of this information stored in a relational database is the ability to report on it. Through Team Foundation, information can be sorted and searched, but there is also the ability to generate standard reports. For example, as part of each project there may be a desire to do some reporting on the bugs reported, still open, and fixed by priority with a summary graph for the project sponsor.

Tools to Enhance Code Quality
Team System also bundles a set of tools providing the developer support for building higher quality code. These tools enable the developer to ensure that code conforms to standards, is thoroughly tested, and performs appropriately.

Many developers have found the static code analysis tool FxCop via GotDotNet. FxCop examines source code to ensure that it conforms to standards and recommends security and performance enhancements. Out of the box, FxCop uses Microsoft's .NET Framework Design Guidelines as the standard by which the code is measured. However, organization-specific rules can be added to FxCop and other rules can be disabled. Additionally, C and C++ developers may currently be using the tool Prefast to analyze their code for C/C++ specific errors. The functionality of Static Analysis (both FxCop and Prefast) has been tightly integrated within the Visual Studio IDE and can be run automatically post-compile rather than outside of the IDE. This enables the developer to obtain useful feedback during each compile and fix any issues found by Static Analysis. The developer can quickly navigate to the offending code and fix it during development. Furthermore, specific rules can be placed on code check-in to ensure that those items that Static Analysis determines are errors can be fixed prior to putting code in the central repository.

One thing nearly every development team could do to improve the quality of their software is to introduce more testing. Most experienced developers use automated unit testing tools during the development process to ensure that future changes to code do not break existing functionality. Some proponents of a process called Test Driven Development even write all of the unit tests prior to writing any code.

Team System introduces a unit test harness within the IDE. Tests are written in code with methods that are marked with the attribute <TestMethod()>. Each test can be categorized so that specific test runs will exercise a specific part of the application. For example, the nightly build may have a certain set of tests that are not run during a build verification triggered by code check-in. Within Visual Studio, there is a test explorer that enables navigation to specific tests or viewing specific categories of tests. There is also a test view that helps the developer write tests.

During unit testing, it's important to understand how much of the code is actually being tested. To assist with this, there is also an integrated unit test coverage tool bundled within Team System. This tool enables a developer to view the code that has been exercised during unit testing. In some cases, a project manager may use this to understand how much of the code is being tested and what percentage of test cases are passing as a quality metric. Note that having significant unit test coverage does not necessarily mean that good unit tests are being applied. Any development team should spend the time to understand how to write good unit tests, and the coverage metrics should not be taken as the only indicator of unit test quality.

In addition to unit testing, performance testing is a crucial part of the development life cycle for many systems. In the past, teams would log events to understand the performance and criticality of specific functions within the system. Team System bundles a set of performance tools that enables developers to obtain statistics about performance of the application at the function level. By understanding which functions are called the most often, along with those that take the most time, developers can hone in on the areas that could provide the most performance benefit.

Building Applications
Historically, building applications for testing or deployment was an activity that one of the members of the team performed (usually the architect). The latest code would be checked out to the architects' machines and they would compile it into a final build. Some of the more savvy architects would write batch files to perform the build.

MSBuild, which ships with Visual Studio 2005, automates the build process through a configuration in XML files. In addition to compiling and creating the latest build, MSBuild can run through a set of tasks such as creating the latest binaries, refreshing the test database, running all of the unit tests, and performing static analysis. The same build files can be configured for different targets so that the same build script can be used to create a test build or a production build just by changing a parameter of the build.

Within Team System, builds can be scheduled to run on a periodic basis with the Team System's build server. This can be used to produce the nightly build and accompanying build verification tests. Additionally, builds can be run whenever a developer checks in new code in Continuous Integration scenarios. In these environments, the entire system can be rebuilt and re-unit tested each time a developer makes a change. If at any moment the build breaks, the culprit is known at that exact point in time.

Conclusion
Team System is a welcome and much-needed addition to the Visual Studio family. Although it was possible to cobble together these tools from vendors and the open source community in the past, it was complex to make it all work together seamlessly. By tightly integrating these tools into the IDE, Microsoft brings together the tools to simplify the developer's life and drastically improve the quality of code produced.

Furthermore, because the tools become a part of the everyday life of the developer, it enables the developer to participate in the full software development life cycle by collecting data unobtrusively about the tasks being performed. This data can be used and analyzed by the project manager or by management to better understand what is happening during application development.

More Stories By Joe Shirey

Joe Shirey is the general manager for the Rocky Mountain region at Interlink Group, LLC, a Denver-based Microsoft Gold Certified Partner. Joe is a Microsoft Regional Director in Denver, a member of the Microsoft Architect Advisory Board, and sits on the .NET Partner Advisory Council.