Identifying the Challenges

The process of working in a distributed team is called geographically distributed development (GDD). Interesting challenges come up when you look at the cultures and approaches of each team. You may have a project that spans several geographies. Additionally, separate projects may be worked on in separate field offices. Other interesting issues that come up are development culture, language differences, process differences, and tools. To address these challenges, you have to look at each project and assess if they are good candidates for Team System. The features, elements, and components that can be distributed include:

• Team Foundation Server

• Branch office infrastructure

• Team portal

• Team Foundation Version Control

• Distributed load testing

• Team Foundation Build

Let's look at each one of these features and explore how they can be applied to a geographically distributed development environment.

Team Foundation Server over The WAN

For secure communication with Team Foundation Server, it is recommended that you access it using a virtual private network (VPN). Most of the applications that connect to Team Foundation Server use a series of Web services. In its release of the server, Microsoft directly supports Integrated Windows Authentication. The problem with Integrated Authentication is that it may not be able to connect through a proxy server (and many ISPs have implemented proxies). Firewalls may also pose a problem for the very same reason. The limitations are well documented in the following knowledge base article: http://support.microsoft.com/kb/916845.

Team Foundation Server Service Pack 1 brings in support for basic and digest authentication. You can see an example of this on Codeplex (codeplex.com), a Microsoft community site hosting open-source applications. This has been implemented using an ISAPI filter that allows Basic Authentication on your extranet.

You can make Team Foundation Server visible on the Web using secure connections such as Secure Socket Layer (SSL). Without Service Pack 1, there are risks involved in exposing the server; so, you should do a thorough analysis. There have been reports of successes using Microsoft Internet Security and Acceleration Server.

Setting Up Your Branch Office Infrastructure

Most companies will have established network and directory infrastructures in each branch office. But how do you integrate them? Setting up a branch office infrastructure involves mass consolidation of services and applications. The goal here is to make administration a lot easier and to simplify authentication and management of users and applications across geographies.

An Enterprise-level branch office reorganization is typically a complex, involved, and expensive process. Microsoft has created a guide called the Branch Office Infrastructure Solution (BOIS) to help simplify the process using Windows Server 2003 R2. You can learn more about BOIS at the following link: www.microsoft.com/technet/itsolutions/branch/.

How does a branch office infrastructure impact Team System? The impact is most felt on two fronts: during deployment and day-to-day management. With regards to deployment, you have to look at scalability and design of your team projects. Will a single Team Foundation Server support your team? Will you need to create different team projects to support different languages, approaches, and methodologies?

From a management perspective, you may need to administer users from different countries using Active Directory. The challenge here is to set up the security structure appropriately to remove dependencies on having to access the server to administer your privileges. Chapter 4 has a great overview on how to consolidate all security administration within Active Directory (AD).

Important

The elements that will make a distributed development environment work are standardization and consolidation. There is nothing more difficult to manage than a potpourri of development practices across a company. By setting standards in process, best practices, and protocols, development will be much easier to manage.

Deploying Your Team Portal on The Web

There are technical considerations to keep in mind if you want to deploy Windows SharePoint Services as an extranet application. Windows SharePoint Services dynamically generates hyperlinks; thanks to Service Pack 2, it now supports reverse proxies, and many Secure Socket Layer (SSL) configurations (such as SSL terminations). A reverse proxy is a single proxy server that acts as a gateway to a farm of Web servers (as shown in Figure 15-2).

Figure 15-2

Important

One of the most asked questions asked about the portal is if the portal can be suppressed or if another established SharePoint site can be used in its place. There is one main strategy you can apply here. To begin, you can create the Team Portal during the Team Project creation process and then change the code in default.aspx in the root of your portal to contain a simple Response.Redirect to your existing or new SharePoint site. (You can use Server.Transfer for performance reasons if your SharePoint site is contained on the same server.) The main disadvantage of this approach is that you will have to recreate the assets (links to reports, work products, and the like) on the other site.

Another scenario is that a reverse proxy may change the header of a SharePoint site in the following way. The client requests a page on the SharePoint site (for example, http://teamportal/default.aspx). The reverse proxy may change the URL to reflect the internal address of the site (http://internal.teamportal). Since the external user doesn't have access to the network past the proxy, the link will be invalid. Windows SharePoint Services Service Pack 2 provides the ability to define both the external and internal URLs to avoid this problem. Check out this blog post on the WSS URL Zone Administration Utility for more information: graphicalwonder.com/?p=122.