Software Requirements To successfully deploy Team Foundation Server, you must take into account the software requirements of each of the components. Here is a drill down of all the required software and additional practical considerations.
Required Service Packs and Software Components At the time of writing, Team Foundation Server itself does not require any service packs. However, we have outlined the service packs for the components that Team Foundation Server depends on (for example, the operating system).
Team Foundation Server Team Foundation Server requires Microsoft Windows Server 2003 with Service Pack 1 (SP1). It will not correctly function on any other current operating systems. To function correctly, the following software components must be installed: Windows SharePoint Services Service Pack 2 (SP2), Internet Information Server 6.0 (IIS, which is packaged with Windows Server 2003), and SQL Server 2005 Standard Edition and above. The key for a successful deployment is installing the components in the right order and correctly configured. The most accurate and complete source of information is the Visual Studio Team Foundation Installation Guide (TFSInstall.chm). The guide can be found on the CD or DVD installation media for Team Foundation Server.
SQL Server 2005 SQL Server 2005 has more flexibility than Team Foundation Server with regards to the operating system (again, assuming that you install the data tier [DT] on a separate machine than the application tier [AT]). SQL Server 2005 requires at least Windows 2000 Advanced or Datacenter Edition with Service Pack 4 or higher. It is fully supported on Windows 2003 Enterprise or Datacenter Edition, or Windows Small Business Server 2003 Service Pack 1 Standard or Premium Edition. SQL Server 2005 has 64-bit support. If you try to run SQL Server 2005 32-bit edition on a server that has an x64 bit processor, it will run in Windows On Windows (WOW64) compatibility mode. Otherwise, SQL Server 2005 will effectively run Windows 2003 Service Pack 64-bit X64 Standard, Enterprise, or Datacenter Edition. Team Foundation Server requires at the very least SQL Server 2005 Standard Edition to run.
Team Foundation Build Team Foundation Build can only be installed on Windows XP Professional with Service Pack 2 (SP2) and Windows Server 2003 with Service Pack 1 (SP1) Standard or Enterprise Edition.
Visual Studio 2005 and Team Explorer Visual Studio 2005 will install on Windows 2000, Windows XP Home and Professional, and Windows Server 2003. Note that Visual Studio 2005 is not supported on the Windows 2000 Datacenter Server. All the editions of Visual Studio 2005 also require Internet Explorer 6.0 with Service Pack 1, Microsoft Office 2003 (or greater) with Service Pack 1, Microsoft Data Access Components (MDAC) Version 9.0, and the .NET Framework 2.0 (which is installed as part off the Visual Studio 2005 installation process). Team Explorer has the same requirements as Visual Studio 2005. It can be used as a standalone tool (a stripped down version of Visual Studio 2005 without any code building functionality). If you have any of the Team Editions installed on your target machine, Team Explorer will install as a plug-in, providing access to Team Foundation Server. Team Explorer is available on the Team Foundation Server CD or DVD media. Figure 1-4 shows a screenshot of the standalone version of Team Explorer. Figure 1-4 If you need to install Visual Studio 2005 on a pre-Service Pack 2 system, Aaron Stebner outlines the steps on his Web log at http://blogs.msdn.com/astebner/. This may be useful if your operations department hasn’t yet deployed Service Pack 2 to all desktops or in test installations.
Other Tools The test controller and test rigs are used to run load tests with a large number of simulated users on remote computers. The test controller requires Microsoft Windows Server 2003 with Service Pack 1 (any version of Windows Server 2003 will do), Microsoft SQL Express Edition, and the .NET Framework 2.0. The test rig must be installed on Microsoft Windows Server 2003 with Service Pack 1, Windows XP Professional with Service Pack 2, or Windows 2000 with Service Pack 4. The test rig also requires Microsoft SQL Express Edition and the .NET Framework 2.0.
Unsupported Software If you want to integrate Microsoft Excel or Microsoft Project with Team Foundation Server, you must install Office 2003 before installing Team Explorer. Earlier versions of Office aren’t supported. If you are running any systems with Windows NT or Windows 98, you will have to upgrade them to Windows XP to connect them to Team Foundation Server.
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. 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: Scenario Action You have VB 6.0 or VC++ 6.0 and You can choose to run Visual Studio 6.0 side-bywould like to import into Team side with Visual Studio 2005. You can then import Foundation Version Control. 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 In most cases, attempting to open and save a .NET .NET 1.0 or 1.1 code in Team System. 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 versioncontrol command-line tool. Another option is upgrading your application to the .NET Framework 2.0. This is facilitated by the builtin 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. 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. 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. 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. 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. 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. Figure 1-6 contains a flowchart that will help you decide what approach to take in the migration (or archiving) of your existing code. 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. 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. 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.
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. 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/.
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.
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. 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. The converter tool is integrated in Visual Studio 2005 and requires the installation of the Guidance Automation Extensions to function.
Licensing Models Cost is always one of the key questions that keep coming up when considering Team System. In this section, we provide guidance and a simplified view to help you understand the licensing model. Here are some practical guidelines to consider:
If your team members perform specific roles without overlap, consider obtaining a specific Team Edition version of Visual Studio for each team member. For example, developers would obtain the Team Edition for Software Developers. If there is overlap between roles, you should perhaps consider obtaining the Team Suite.
Team Foundation Server requires a license, and every computer accessing the server using Team Explorer (or any other client) requires a client access license (CAL). In some instances involving a remote “non-employee,” a connector can be purchased to allow them access to the server.
Each instance of Team Foundation Server Proxy requires a Team Foundation Server license. A license is also required for “warm” failover instances of Team Foundation Server.
Where to Get Team System
There are four primary ways of obtaining Team System:
Retail—The components of Team System are available from retail outlets (such as Amazon.com). If you are buying the product retail, keep in mind that (a) you are paying full price, and (b) you are not going to benefit from Software Assurance (SA). Software Assurance guarantees that if Microsoft releases any Team System products off band (such as Team Edition for Database Professionals), you will get a license for it at no extra cost. It also applies if something like a “Team Foundation Server R2” gets released; you will be entitled to a copy.
Reseller—Resellers such as SoftChoice provide good value because they have licensing experts that can find and tailor a licensing package to your situation and environment.
MSDN Subscriber Downloads—If you get a combination of Partner, Academic or GSI Programs and own a MSDN subscription, you may also be able to benefit from substantial savings by upgrading to Team System. You can view more information about each option at the following link: http://msdn.microsoft.com/vstudio/howtobuy/.
If you plan to use all the testing feature integration with Team Foundation Build, you should obtain a license for Team Edition for Software Developers and Team Edition for Software Testers (or Team Suite). The combination of these two products provides the necessary framework to run any of the tests commonly found in Team System. Note that both these products must be installed on the build server. The best source of information for licensing is a whitepaper published on MSDN. To access the whitepaper, refer to http://go.microsoft.com/fwlink/?LinkId=55933.
Summary
This chapter introduced Team Foundation Server including its underlying architecture and the components of the product. Next, you learned how to compile your project data, including assessing security, client, and server requirements. Later in the chapter, you learned how to plan a deployment and looked at the practical hardware considerations for the smooth operation of the product. You then looked at migration and integration scenarios for each one of the Team Foundation Server components. Finally, you learned about the Team System licensing model and a little about the costs involved. In the next chapter, you will learn in detail about advanced installation topics and drill down on scenarios to put all of your planning into action.
Click Here to Purchase this Book