Considerations for Migrating and Integrating Your Existing Tools

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 capability to do large-scale load tests out of the box; therefore, it makes sense to migrate if you are already paying thousands of dollars supporting and licensing a third-party tool because the migration process will result in a cost savings.

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.

In this section "Considerations for Migrating and Integrating Your Existing Tools," we will look at some of the important features of Team Foundation Server and discuss the challenges and resources available to help you migrate and integrate your existing solutions to Team System. This is not meant to be an exhaustive list but will provide you with a good starting point.

Note

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

Version control

When looking at source control, the main question you have to ask yourself is whether it makes more sense to maintain the current source control system or to migrate your source projects to Team Foundation version control. If your company has invested tens and hundreds of thousands on a source- control system, it may not be in your best interest from a business perspective to migrate all your code. On the other hand, if you are planning new development using Visual Studio 2005 and the .NET Framework 2.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.

One of the logical migration paths is moving your code from Visual SourceSafe to Team System. Visual SourceSafe is a good tool for 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 for the first time concurrent check-ins and rollback capabilities.

Note

One of the biggest misconceptions about Team System's version control is that it is the new version of Visual SourceSafe. This is completely untrue — 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 enable you to migrate your Visual SourceSafe code to Team System. You can find out more details here: http://www.msdn2.microsoft.com/en-us/library/ms253060.aspx

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 using these systems directly. If you choose another source control system, keep in mind that 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 enable you to connect and transmit information from Team Foundation Server to your source control system and vice-versa.

Work-item tracking

Work-item tracking is an important feature of Team Foundation Server for two reasons: One, it provides a way for your team members to track workflow and collaborate right from within Visual Studio. Two, it also 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.

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 in the end.

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 the following URL: http://www.msdn2.microsoft.com/enus/library/ms253046(en-US,VS.80).aspx.

You may also be tracking workflow by 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 the following URL: http://www.gotdotnet.com/workspaces/workspace.aspx?id=.

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 such a report. There are also other tools such as Crystal Reports that will provide the capability to generate graphs and other reports from raw data. One of the disadvantages with third-party tools (such as Crystal Reports) is that they can be expensive and complicated to use.

Team System's reporting capabilities are provided by 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 external data into SQL Server 2005, you can then mine and view the data in an integrated way within Team System.

Testing tools

Team System incorporates a great number of testing tools, including dynamic analysis, code analysis, manual testing, load testing, unit testing, ordered testing, Web testing, and performance testing.

James Newkirk created a migration tool to port over NUnit tests to Team System called the NUnit Converter. Note that unit testing is fully integrated into the toolset as the Unit Test Framework. Note, too, 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: http://www.gotdotnet.com.

Note

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 enables you to run external executables (with parameters) and import results back into Team System's testing framework.