Migrating and Integrating Your Existing Tools and Assets

When you look at how you can work within Team System, you have to consider whether it makes more sense to migrate or integrate your existing tools into Team System. Migration makes a lot of sense if you want to rid yourself of expensive third-party licensing agreements. For example, Team System provides the ability to do large-scale load tests and obviates the necessity of paying thousands of dollars to support and license a third-party tool.

Integration is a smart option if you have invested a lot of money on existing tools and you wish to leverage that investment. Integration is a little trickier because it often entails extra configuration and programming steps to make both systems "talk" to and integrate with each other. Let's take NUnit as an example of a tool that is very popular and does not have a great integration story with Team Foundation Server. Sure, you can migrate your NUnit code over to the Unit Test Framework within Team System using the migration tool. But if you want true integration with NUnit, you would have to create tools using Team Foundation Server's extensibility hook, which would perform the translation back and forth and allow Team Foundation Server to "understand" the code in build verification tests, during checkins, and so forth.

In this section, we will look at the core features of Team Foundation Server and discuss the challenges and resources available to help you migrate and integrate your existing solutions to Team System.

Important

When making a decision about integration or migration, it is important to discuss the implications with a knowledgeable systems integrator or consultant. While a decision may seem straightforward, it may have cost, technical, and architectural implications. It is important that whoever you decide to work with has a solid background on Team System and your existing tools.

Version Control

Most of the core components of Team Foundation Server are designed to work with the .NET Framework 2.0. This makes Team System a very appealing candidate if you are planning to develop an application from scratch using Visual Studio 2005.

But what should you do if your application was built in VB6 or the .NET Framework 1.1? Here is a matrix covering the common scenarios you may encounter:

Open table as spreadsheet

Scenario	Action
You have VB 6.0 or VC++ 6.0 and would like to import into Team Foundation Version Control.	You can choose to run Visual Studio 6.0 side-by-side with Visual Studio 2005. You can then import Visual Studio 6.0 projects into Team Foundation Version Control using the command-line tool or the MSSCCI client.
	Another option is to convert your code from VB or VC++ 6.0 to the .NET Framework 2.0. For example, if you attempt to open a VB 6.0 project in Visual Studio 2005, an upgrade wizard appears. There is also a lot of migration documentation on the MSDN Web site at http://msdn2.microsoft.com/en-us/library/.
You would like to import and build .NET 1.0 or 1.1 code in Team System.	In most cases, attempting to open and save a .NET 1.0 or 1.1 solution in Visual Studio 2005 will result in solution that will no longer open in Visual Studio 2002 or 2003. The reason for this is that Visual Studio 2005 supports the .NET Framework 2.0 only.
	So, what are your options? You can install Visual Studio 2002/2003 and Visual Studio 2005 side-by-side. By opening your older solutions in the older versions of Visual Studio, you will avoid any migration issues. However, until a Team Foundation Source Control plug-in is developed for Visual Studio 2003, the only way you will be able to import your code in Team Foundation Version Control is by using the version-control command-line tool.
	Another option is upgrading your application to the .NET Framework 2.0. This is facilitated by the built-in upgrade wizard. The downside is that you will have to deal with migration issues; however, the upside is that you will be able to import and export your source code using Team Explorer.
	There are two tools available to build .NET 1.1 within Team Foundation Build. The first tool is called MSBuild Toolkit and is available at http://downloads.interscapeusa.com/MSBuildToolkit_v2_RC .msi.
	The second tool is called MSBee - MSBuild Everett Environment. It is being developed by Microsoft. More information is available at http://blogs.msdn.com/clichten/.

For ASP.NET 1.0 or 1.1 code, there is a migration wizard to help you migrate your application to ASP.NET 2.0. The easiest way to migrate 1.0 Web services is to recreate them in 2.0 and copy and paste your source code.

Important

Keep in mind that launching ASP.NET 2.0 Web sites will automatically launch the local Cassini Web Developer server by default. You should configure the virtual directory in your IIS server to host your application and set Visual Studio to launch without Cassini to get a similar experience as earlier ASP.NET applications. ASP 3.0 applications are compatible but will not compile.

What if you have code designed for a different platform, for example, Java code? Team Foundation Version Control is versatile and can store different file types including Java projects. Obviously, code from other platforms will not integrate as nicely with the testing tools and the build engine. However, you could launch builds on other platforms using custom build tasks, and integrate external testing tools using either build tasks or generic tests.

Teamprise (teamprise.com), one of Microsoft's VSIP customers, has developed a plug-in to allow Eclipse to integrate with Team Foundation Version Control and Team Foundation's work item tracking. Before you decide to integrate code from other platform, however, you must first configure the file types by clicking on Team⇨Team Foundation Server Settings⇨Source Control File Types. The window shown in Figure 1-5 displays.

Figure 1-5

Simply add the required file type and you are ready to go. Be sure to select Disabled file merging if your files are binaries or nonsource code files.

Important

You will have different levels of support for languages in Team System depending on the language. For example, there is great support for Java in the IDE, whereas other languages are "less" supported. Of course, you can integrate anything with Team System. All that is required is ingenuity and effort.

When looking at source control, the main question you have to ask yourself is if it makes more sense to maintain the current version or source-control system, or migrate your source projects to Team Foundation Version Control. If your company has invested tens and hundreds of thousands on a sourcecontrol system, it may not be in your best interest from a business perspective to migrate all your code. However, if you are planning new development using Visual Studio 2005 and the .NET Framework 2.0 (or .NET Framework 3.0), starting a project within Team System will be a good decision, as you will be able to leverage the deep integration between Visual Studio and Team Foundation Version Control.

Important

One of the most important considerations in deciding whether to move your source code to Team System is your history. If the history isn't crucial, then you can check out all of your code and check it into Team Foundation Version Control. If it is important, then you may choose to migrate your code (using the Visual SourceSafe migration tool, a third-party tool like ComponentWare's Converter, or your own custom migration tool using the Team Foundation Version Control API), maintain the code in the existing repository, or even just keep an archive of your "old" code and begin new development on the new platform.

Figure 1-6 contains a flowchart that will help you decide what approach to take in the migration (or archiving) of your existing code.

Figure 1-6

One of the most popular migration paths is moving code from Visual SourceSafe to Team System. Visual SourceSafe is a good tool for a small development projects with a small number of developers. However, it does not scale well if your team grows beyond a dozen developers and testers. Team Foundation Version Control is designed to manage large teams of developers and provides first time concurrent check-ins and rollback capabilities.

Important

One of the biggest misconceptions about Team System's version control is that it is the new version of Visual SourceSafe. This is incorrect; Team System Version Control was written from scratch for Team System and uses SQL Server 2005 as a means of scaling to larger environments and infrastructures.

Microsoft has developed a migration tool called VSSConverter to allow you to migrate your Visual SourceSafe code to Team System. You can find out more details in this MSDN article at http://msdn2.microsoft.com/en-us/library/ms253060.aspx and in Chapter 12 in this book.

What if you are using other version control systems such as CVS or SourceGear? Team System does not support these systems out of the box, but nothing prevents you from leveraging these systems directly. If you choose another source control system, keep in mind you will not be able to use the build engine. (Team Foundation Build pulls the sources out of source control before building them.)

What if you want to integrate an existing source-control system with Team System? Luckily, there are a lot of projects in the works to help you. Team Foundation Server provides a wide variety of APIs to allow you to connect and transmit information from Team Foundation Server to your source-control system and vice-versa.

Important

Anything that has to do with extensibility is covered in Chapter 9, and can also be found within the Visual Studio 2005 Software Development Kit, which you can download from http://affiliate.vsipmembers.com/.

Work Item Tracking

Work item tracking is an important feature of Team Foundation Server for two reasons: First, it provides a way for your team members to track workflow and collaborate right from within Visual Studio. Second, it provides the important link to implementing your process. For example, if the process you are using has a predefined iterative flow, you can create a series of tasks or requirements that will support and enact the iterations and establish your process.

Work item tracking is a baked-in and highly integrated way of managing your work within Team System. But what if you have invested work or budget on other tools? As with any other feature of Team System, you are not forced to use the feature. You can selectively pick what you prefer to use.

If you wish to move over your ClearQuest workflow to the Team System work item database, Microsoft provides a ClearQuest migration tool called WIConverter to help you out. You can learn more about the migration tool at http://msdn2.microsoft.com/en-us/library/ms253046(en-US,VS.80).aspx.

You may also be tracking workflow using Microsoft Office Project Server 2003. Fortunately, there are efforts under way to integrate both Team System and Project Server using a special connector. You can learn more about the connector at gotdotnet.com/workspaces/workspace.aspx?id=b9f69ea5-ace1–4a21–846f-6222a507cc9c.

The chart in Figure 1-7 shows the different decisions you can make in regards to migrating or integrating your existing work items within Team Foundation Server.

Figure 1-7

Reporting

Team System does an amazing thing with reporting: It automatically aggregates project data such as build quality stats, bug counts, work item completion statistics and much more. In the past, you had to manually aggregate all your data by hand and import it into Excel to generate a report. Other tools like Crystal Reports provide the ability to generate graphs and other reports from raw data. One of the disadvantages with third-party tools is that they can be expensive.

Team System leverages SQL Server Reporting Services. Visual Studio 2005 provides a Report Designer to help you create new kinds of reports that can be viewed on the report site. The main idea here is that if you can bring in external data into SQL Server 2005, you can then mine and view the data in an integrated way within Team System.

You can create custom reports using the Report Designer or Excel. You can also create custom work items that contain reportable fields that can be integrated within a custom report. To learn how to create your own reports, refer to Chapter 16.

Build Server

One of the scenarios you may encounter is that you may want to transfer your NAnt scripts (or other build scripts) to Team System. Unfortunately, there is no established tool to help you do this. However, MSDN Channel 9 has a task equivalency chart that shows you the differences and similarities between MSBuild and NAnt. You can view the chart at http://channe19.msdn.com/wiki/default.aspx/MSBuild.EquivalentTasks.

In migrating or converting a script from one platform to another, the trick is sometimes just to find the right custom task to do the job. GotDotNet has a great repository of prebuilt custom build tasks at http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=2cb20e79-d706–4706–9ea0–26188257ee7d. The GotDotNet project is called ".NET SDC Solution Build & Deployment Process & Tools." You can also download a number of useful open-source build tasks from Tigris. The download link is http://msbuildtasks.tigris.org/.

Figure 1-8 shows the decision path to determine if you want to integrate your existing tools (such as CruiseControl) with Team Foundation Server. If you want to migrate your tasks, then there are equivalency charts and custom tasks that will facilitate the process.

Figure 1-8

Testing Tools

Team System incorporates many testing tools including dynamic analysis, code analysis, manual testing, load testing, unit testing, ordered testing, Web testing, and performance testing.

NUnit Converter is a migration tool created by James Newkirk to port NUnit tests to Team System. Note that unit testing is fully integrated into the toolset as the Unit Test Framework. Note that this framework is available only in the Team Edition for Software Developers, Team Edition for Software Testers, and Team Suite versions of Visual Studio 2005. The migration tool is available on the NUnit Add-ons workspace on GotDotNet at http://www.gotdotnet.com.

Important

The converter tool is integrated in Visual Studio 2005 and requires the installation of the Guidance Automation Extensions to function.

In terms of load testing, Team System comes with an integrated tool. From a practical standpoint, one of the core advantages of the load-testing tool is that it is available to the entire software development team and is a great deal less expensive (from a licensing perspective) than other third-party tools. Another advantage is that the Team System load tester can support a great number of concurrent users.

Unfortunately, at the time of writing there aren't any migration tools to help you migrate Mercury Loadrunner tests to Team System. However, it is possible to integrate the Loadrunner tool using a generic test. The generic test allows you to run external executables (with parameters) and import results into Team System's testing framework.