Professional Team Foundation Server 2013 (2013)

What's in this chapter?

· Understanding the difficulties of a distributed development environment

· Getting to know Team Foundation Server Proxy

· Learning techniques for working with remote teams

· Dealing with build servers in a distributed environment

· Introducing Team Foundation Server Integration Tools

· Understanding how to be effective when the server is not available

The development of software by distributed teams is a growing trend. People are working in a global economy with greater competition and choice. There are many reasons you may be working with a distributed team, including the following:

· Your company has grown and expanded, and it has several field offices.

· Your company contracts out portions of development to third parties.

· Your company merged with another company and both companies must work interactively over great distances.

Even if you don't work in a distributed team, you may work in an environment whereby your server infrastructure is located at a different physical location. Following are a few examples:

· Your IT infrastructure is outsourced to another company—for example, using the Visual Studio Online hosted by Microsoft.

· Your development team is located in a different city from the main office to take advantage of skilled workers in that area.

· You have a mobile workforce that moves between offices and has no main office.

When you work with Team Foundation Server 2013 in this environment, there are a number of challenges that you will face and specific issues you are more likely to encounter as a result of having physically separated teams. This chapter explores those challenges and ways that you can overcome them.

Team Foundation Server 2013 was built with these geographical challenges in mind. In this chapter, you'll learn about the capabilities of Team Foundation Server that allow you to overcome these boundaries and collaborate as a cohesive team, whether separated by feet or by oceans.

Identifying the Challenges

You face a number of challenges when working with geographically distributed teams. This chapter walks you through the challenges most relevant to your Team Foundation Server environment.

Latency over the Wide Area Network

Perhaps the biggest technical challenge that distributed teams will face is the network connection that separates them and the server. Network connectivity can be affected by many different factors. However, the biggest factor is latency.

Latency is the time that it takes for packets of data to travel between two points. Think of when you connect a garden hose to a tap and then turn it on. There is a delay between when you turn on the tap and when water starts pouring out the other end. This delay is called latency. Latency in a networking context can be “one-way” or “round-trip.” Round-trip latency is the time it takes data to travel from the client to the server and back again. It is usually measured by running the ping command against a server.

On a local area network (LAN), typical round-trip latency is less than five milliseconds. Between two computers within the same continent, typical round-trip latency is less than 100 milliseconds.

What's important to realize is that regardless of the speed of your Internet connection, your latency can never beat the speed of light. The speed of light in fiber-optic cable is roughly 35 percent slower than in a vacuum. As an example, the shortest distance between Sydney, Australia, and Seattle, Washington, is about 8,000 miles, or 12,000 kilometers. Therefore, the absolute minimum one-way latency is 60 milliseconds, and the round-trip latency is 120 milliseconds. In reality, though, the cables don't run directly between two points, so the latency is higher because of this and intermediate network equipment.

Another aspect of latency is that it isn't always symmetric. Latency could be greater in one direction compared to the other. This can be seen when using a one-way satellite Internet connection. The upstream data is sent using a landline, and the downstream data is received via a satellite dish. Because the data must travel from the Internet to a base station, to the satellite, and then back down to the receiving dish, typical round-trip latency is 300 milliseconds.

Microsoft recommends that a server running Team Foundation Server should have a reliable network connection with a minimum bandwidth of 1 Mbps and a maximum latency of 350 milliseconds.

Sources of Network Traffic

Many different sources of network traffic exist within the components of a Team Foundation Server environment. Table 28.1 details the contribution of each component, which will vary in each environment. In most environments, version control and work item tracking are typically the biggest contributors. Depending on your configuration, virtual machine deployments from Lab Management can be a large contributor.

Table 28.1 Network Traffic Associated with Each Component

Version Control

Version control in a Team Foundation Server environment will almost always be the largest contributor to network traffic. There are two sources of traffic:

· User commands

· File content downloads

Whenever a client performs a Get (if using Team Foundation Version Control) or a Pull (if using Git), the server will send the entire contents of any file that has changed to the client. The more clients you have, the more traffic there is. The amount of traffic is also proportional to the number, frequency, and size of files that change in the repository.

Work Item Tracking

Work item tracking has three main sources of traffic:

· User commands (queries, opens, saves, and bulk updates)

· Metadata Cache downloads

· Attachment downloads and uploads

The biggest contributor of these three is usually the Metadata Cache.

Every team project has a set of metadata that includes work item rules, global lists, form layouts, and other project settings. The more team projects that you have and that people have access to, the more metadata that needs to be potentially sent to each of the clients. There is a linear relationship in the metadata size increase and the number of team projects even if each of the team projects uses the same process template.

Whenever a client communicates with the server to perform a work item–related query, it tells the server what version of the metadata it is using. The server then sends back all the metadata that it doesn't know about yet, along with the data the client was actually asking for. This is called a Metadata Refresh. There are two types of Metadata Refreshes: incremental and full.

In Team Foundation Server 2008, certain administrative operations such as deleting a field caused the Metadata Cache to be invalidated. All clients would then download the full Metadata Cache the next time they performed a query.

In Team Foundation Server 2010, 2012, and 2013, almost all operations that invalidate the cache will use an incremental update. This means that not only the load on the server (in the form of memory pressure and metadata requests) is greatly reduced, but also the overall network traffic to the client is reduced.

Note

To measure the work item tracking Metadata Cache size, on any client computer, locate the C:\Users\<user>\AppData\Local\Microsoft\Team Foundation\5.0\Cache folder. Right-click a subdirectory that has a GUID as the name, select Properties, and read the size in the Properties dialog box. Remember that the Metadata Cache is likely to be compressed when it travels over the network, so you might have to use a network traffic sniffer such as NetMon to see the actual network transfer size, rather than looking at the folder size.

Problems with Metadata Cache Refreshes at Microsoft

Because of the level of process template customization by various teams at Microsoft, there were a lot of unique fields, rules, and work items on the internal servers. In an effort to clean up some of the fields and consolidate them, the project administrators started to delete the unused fields.

This field deletion caused the Metadata Cache to be invalidated and forced all clients to perform a full Metadata Cache refresh. The combination of a large Metadata Cache and a large number of clients effectively took the server offline by consuming all the memory available, and all available connections, while the clients refreshed their caches.

As a brute-force work-around before metadata filtering was available, the team renamed the stored procedure that invalidated the cache to prevent the problem from happening during business hours. Then, if there was a need to delete the fields and invalidate the cache, the team would rename it back and run the command on a weekend. The cache refreshes would then be staggered as people arrived at work on Monday and connected to the server.

Visual Studio 2010, 2012, and 2013 clients perform an incremental update if a field is deleted on the server, so this is no longer a problem.

Solutions

You have a number of different ways to overcome the challenges of working with geographically distributed teams. Each of these solutions can be used by itself or combined with others to fit your needs.

Using Visual Studio Online Geographically Distributed

Using the Microsoft-hosted Visual Studio Online is the easiest way to offload a large portion of the infrastructure required by Team Foundation Server. A scalable cloud infrastructure greatly simplifies deployment and is a great way to avoid worrying about increased server load when your team grows.

There are drawbacks for some distributed teams, however. Because the service is hosted in the cloud, all communication happens via the Internet. This can result in significantly greater latency than you would find with a server deployed on a local network. If most of your team is in one office and only a few users need access from another geographic location, this solution may not be appropriate.

In some organizations, it is not acceptable for any intellectual property to be hosted on third-party infrastructure. This is especially true in highly regulated environments such as governmental, defense, and financial industries. In this case, a hosted solution such as Visual Studio Online may be immediately ruled out.

The benefits of using hosted server infrastructure can be substantial for teams that are distributed across the globe. It is certainly the simplest solution for providing access to anyone in any location, but it may come with increased latency for some or all of your users.

Central Server with Remote Proxy Servers

The Team Foundation Server Proxy is a server that is capable of caching downloads of files from version control and test result attachments. It is discussed later in this chapter. This is the recommended and simplest environment to configure and maintain. It is the best choice when your users are working from branch offices that can host remote proxy servers.

However, the drawback is that if your users are evenly spread around the world, then there is no central place to locate the server, and latency will be a problem for everybody. You will want to place proxy servers in each of the remote locations.

Multiple Distributed Servers

If your distributed teams are working on different products that can be developed in isolation of each other, then running multiple servers may be an option. This has the benefit of allowing people to work with a local server on their projects. The drawback, of course, is that there are now multiple servers to maintain, along with codebases in different repositories. Additionally, reporting and managing software releases and resources across multiple Team Foundation Server instances becomes quite challenging.

The remote team could host its own Team Foundation Server and maintain a dedicated team project collection. Then, when it comes time to hand off the product to the in-house maintenance team, the collection can be detached from the remote server, backed up, and then attached to the local server.

Note

For more information on this procedure, see the “Move a Team Project Collection” page on MSDN at http://aka.ms/TFSMoveTPC.

Mirroring

If your development cannot be partitioned between the different remote sites, then one option is to use the Team Foundation Server Integration Tools to mirror source code and work items between the different Team Foundation Server environments. This may sound like the silver bullet that can solve all of your problems, but it is not without a large cost.

Every mirror that you set up has overhead associated with it. When people are depending upon the mirror, its operation and maintenance must be taken just as seriously as running the Team Foundation Server environments themselves. This topic will be looked at in more detail later in this chapter.

Remote Desktops

As mentioned earlier, in some environments, it is not acceptable to have intellectual property stored on remote machines outside the IT department's control.

One solution for these environments is to maintain a central Team Foundation Server along with Remote Desktop Services (RDS) or other Virtual Desktop Infrastructure (VDI) for clients. Essentially, a remote user will connect to a virtual desktop on the same network as the central server. The only traffic that must travel across the network is the keyboard and mouse input and the video output. However, depending on your usage of Team Foundation Server, this may require more bandwidth than not using Remote Desktops.

Internet-Connected “Extranet” Server

Virtual Private Networks (VPNs) and other remote access technologies can become a bottleneck compared to accessing servers directly over the Internet. If you have teams clustered at remote sites, the site(s) will often have a dedicated VPN that has less overall overhead and usually a better network connection. However, if you have mobile workers spread around the world, they will often be able to get a better Internet connection from their local ISP than connecting to the corporate network.

By exposing your server directly on the Internet, you allow people to connect directly to it without having the overhead of encapsulating their traffic in a VPN tunnel. If you decide to connect your Team Foundation Server to the Internet, you should consider enabling and requiring the HTTP over SSL (HTTPS) protocol to encrypt the traffic to and from the server. The hosted Visual Studio Online by Microsoft uses this approach.

Metadata Filtering

As mentioned earlier in this chapter, the Metadata Cache has the potential to become a huge source of network traffic. When metadata filtering is enabled, the server will send the minimum amount of metadata required for the project that you are connecting to. This can reduce the network traffic if people generally connect to only one team project.

The downside is that the Metadata Cache is invalidated each time you connect to a new server. This can especially be a hindrance if people connect to more than one team project on the server. In this case, the server will be sending some of the same metadata each time they connect. It would be more efficient to download the full metadata for all team projects just once.

Note

More information on how metadata filtering works and how to enable it can be found on Martin Woodward's blog at http://aka.ms/TFSMetadataFiltering.

Build Servers

When you work in a geographically distributed team, the availability of nightly builds to your testers can be an important decision point. You have a few different options available, and each has different benefits and trade-offs.

Local Build Server Farm

This is the most common scenario for small to midsized teams, where the build server farm is in the same location as the Team Foundation Server environment itself. In this scenario, the speed of the build isn't affected by the speed of the WAN. If you are using the hosted Visual Studio Online, a hosted build controller is available to you.

The downside of this approach is that it will take time and use WAN bandwidth for remote teams to get the build outputs. Additionally, unless you use some other caching technology, or set up a script to copy build outputs to remote sites, then everyone at the remote sites will be transferring the same files over the WAN multiple times. This is slow and can be expensive if you are charged for WAN traffic.

Alternately, useful features are available in Windows Server 2008 R2 and Windows Server 2012 for hosting a file share that can be cached or distributed appropriately for this scenario. For example, you could use Distributed File System (DFS) or BranchCache to expose the same UNC path but have Active Directory locate the closest file server with the actual file content. If you do take this approach, be sure to use the UNC path in the build definition that has DFS or BranchCache enabled instead of a UNC path that contains a hard-coded server name in it. Friendly DNS names as described in Chapter 2 would be a perfect choice for both the Build Drops and Symbol Server file shares.

Remote Build Server Farm

In this scenario, you would situate build servers at your remote locations. Combining this with a Team Foundation Server Proxy at each remote site, you get a good solution. The build servers have access to a local cache as facilitated by the proxy server, and the developers have access to local build outputs. However, if multiple teams need the ability to access the same build drops and Symbol Server store, then you may want to consider the options for caching/synchronizing file shares as mentioned in the previous section.

Note

Team Foundation Server Builds are discussed in detail in Part IV of this book.

Team Foundation Server Proxy

The Team Foundation Server Proxy is a server capable of caching downloads of files from version control. Additionally, the Team Foundation Server Proxy for the 2012 release has introduced the ability to also cache test result attachments, which can be quite large. Types of test result attachments are those that come from the different diagnostic data adapters that are run during test runs such as IntelliTrace, video recorder, code coverage, and so on. Even if you don't have a geographically distributed team, there are features that will be useful to all teams that use version control, including for local build server farms and local teams.

How the Team Foundation Server Proxy Works

The Team Foundation Server Proxy server is used purely for Team Foundation Version Control downloads and caching test result attachments. It is not yet used for work item tracking attachments or other functions in Team Foundation Server. Typically, the proxy server is used at remote offices to improve the performance of version control downloads and test result attachments. However, it can (and should) be a part of any reasonably busy Team Foundation Server environment topology.

Note

For more detailed information on how the Team Foundation Server Proxy works, refer to http://tinyurl.com/HowTFSProxyWorks. This article was written for the Team Foundation Server 2008 product but still applies for version control downloads.

Compatibility

The 2008, 2010, 2012, and 2013 proxy servers can act as proxies for Team Foundation Server 2008, 2010, 2012, and 2013. Each of those versions can proxy for multiple Team Foundation Server instances and team project collections. When a 2010, 2012, or 2013 proxy server is configured and given access to a Team Foundation Server 2010, 2012, or 2013 server instance, it automatically proxies requests for all team project collections on that instance. This is useful when you add new collections to a server, because you don't need to do anything special to set up the proxy to be available for those collections.

It is important to note that only Team Foundation Server 2012 and 2013 proxy servers have the ability to cache test result attachments from a Team Foundation Server 2012 or 2013 environment. This is true with the different clients available such as Visual Studio 2013 and Microsoft Test Manager 2013. The earlier versions of the clients and proxy servers will not have the necessary functionality to cache test result attachments since it was newly introduced in the 2012 release.

Configuring Proxies

A proxy server doesn't necessarily have to be registered with the Team Foundation Server to be used. The only requirement is that the service account under which the proxy server runs must have the “View collection-level information” permission for each project collection.

The easiest way to set this up is to add the proxy service account to the built-in server-level group:

[TEAM FOUNDATION]\Team Foundation Proxy Service Accounts

Each team project collection has its own group that the server-level group is a member of:

[DefaultCollection]\Project Collection Proxy Service Accounts

If you are setting up a proxy server for use by all users at a particular remote location, you'll want to do these three things:

· Run the proxy as the built-in Network Service account so that you don't have to update the service account password every time it changes.

· Add the proxy service account to the server-level group on each server that you want it to proxy for.

· Register the proxy server with the server, and set it as the default for the Active Directory site(s) that the proxy server is located in or should serve as the proxy server for other locations. There are additional details on how to accomplish this later in this chapter.

Note

To register a proxy server, substitute your own Active Directory site and TFS environment friendly DNS names when you use the following command from any client with appropriate permissions:

tf proxy

/add http://ProxyFriendlyDNS:8081/VersionControlProxy

/site:US-WA-REDMOND /default:site

/collection:http://ServerFriendlyDNS:8080/tfs/DefaultCollection

Proxy Cleanup Settings

A proxy server will perform best when it has a copy of the files that people most often request. In reality, that's easier said than done because it's difficult to predict which version of which files people are going to want before they actually request them. To deal with this, the proxy will keep a copy in its cache of every version of every file that is requested. Without any cleanup, the cache directory will eventually fill to capacity.

The proxy has a built-in cleanup job designed to delete older files and make space available for more recently requested files. You can express the cache limit in many ways, including as a percentage of disk space. For example, the proxy cache with the following configuration can take up only 75 percent of your hard drive space.

<PercentageBasedPolicy>75</PercentageBasedPolicy>

You can also express your cache limit as a fixed number of megabytes, as shown here:

<FixedSizeBasedPolicy>1000</FixedSizeBasedPolicy>

The cleanup will trigger when the cache size exceeds the threshold.

Note

For more information on these cache settings and how to change them, see “How to: Change Cache Settings for Team Foundation Server Proxy” at http://aka.ms/TFSProxyCacheSettings.

Automatically Detecting the Proxy Settings

A feature in Team Foundation Server, introduced in Team Foundation Server 2010, allows a proxy server to be registered with the collection. This means that users don't have to know which proxy server they should be using. In addition to the tf proxy /configurecommand, the Visual Studio IDE will automatically query and set a default proxy server if one is registered on the server. This is achieved through the GetBestProxies method in the version control object model.

Active Directory Sites

The physical structure of a Windows network is defined in Active Directory as a site. A site contains one or more subnet objects. Typically, a remote office will have its own subnet and will be defined as a separate site.

Team Foundation Server leverages this infrastructure and allows you to define a default proxy server for each site in Active Directory. As an example, the Team Foundation Server and Visual Studio ALM product teams are split between Raleigh, North Carolina; Hyderabad, India; and Redmond, Washington. The corporate network has the Raleigh and Hyderabad offices configured as a separate Active Directory site to the Redmond office. When a developer travels from one office to the other, and connects to the office network, the Visual Studio client automatically detects the new site and reconfigures itself to use the default proxy for that site.

You will likely need to work with your Active Directory administrators in the IT department to work out which sites should be used. You can see what is configured for your network as well if you have the Remote Server Administration Tools for Windows features installed on your local Windows machine. Open the Active Directory Sites and Services utility from the Start Administration Tools folder and you will see each of the sites defined in Active Directory for your Windows network. A sample set of Active Directory sites is shown in Figure 28.1.

Figure 28.1 Active Directory sites and services

Setting a Proxy

The version control proxy settings are a per-user and per-machine setting. To force your client to configure the default proxy for the site, you can run the following commands:

tf.exe proxy /configure

tf.exe proxy /enabled:true

You can query registry keys to see if you have a proxy configured by running the following commands:

reg.exe query HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\

TeamFoundation\SourceControl\Proxy /v Enabled

reg.exe query HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\

TeamFoundation\SourceControl\Proxy /v Url

You can also set registry keys to enable a proxy server without using tf.exe by running the following commands (replacing the proxy server name with your own):

reg.exe add HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\

TeamFoundation\SourceControl\Proxy /v Enabled /d True /f

reg.exe reg add HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\

TeamFoundation\SourceControl\Proxy

/v Url /d http://redmond.proxy.tfs.contoso.local:8081 /f

Although it's not documented or officially supported, you can also set the TFSPROXY environment variable, and any client that uses the version control object model will use the proxy.

set TFSPROXY=http://redmond.proxy.tfs.contoso.local:8081

Seeding Proxies

As mentioned earlier in this chapter, the proxy server will cache a copy of a file only if someone requests it. Because of this, you may want to implement a process that will seed the proxy with the most commonly used files in an off-peak period, or after a period of high churn.

As an example, for the Team Foundation Server product team at Microsoft, the main servers are located in Washington on the West Coast. The other half of the team is in North Carolina on the East Coast. The nightly build checks in some of the build outputs to source control. These binary files can be quite large, and the bandwidth at the remote site is often strained during the day.

The team implemented a scheduled task at the remote site that requests the latest versions from the main server after the build has completed. Because the proxy server doesn't have these versions, it then downloads them and caches a copy. This means that the first person who needs those files the following day doesn't have to wait for the lengthy download, and that person gets sent the cached copy from the proxy server.

Using scheduled tasks is one approach to this problem. Another approach is to set up a build server at the remote site. The first part of a build is generally to create a workspace and get the latest version of the source code. If this build is set up to run nightly, or build every check-in (in other words, a continuous integration build), then it will keep the contents of the proxy fresh for other users of that code.

Personal Proxies

A personal proxy server is useful if you do not have a remote office with a proxy server near you. By setting up your own personal proxy server, you will have to download a file's contents only once.

One of the changes, introduced in the 2010 release, in the Team Foundation Server license agreement, is that each MSDN subscription provides a license to deploy one instance of Team Foundation Server into production on one device. Since Team Foundation Server Proxy is just a different configuration of the product, this means that each user with an MSDN subscription could run a personal proxy server or use the production license for a remote office proxy server.

Note

For the full details, see the “Visual Studio Licensing” whitepaper at http://aka.ms/VisualStudioLicensing and your applicable licensing agreements.

Mirroring with the Team Foundation Server Integration Tools

In the past, there was a download available on CodePlex called the “TFS Migration Synchronization Toolkit.” The intention of the toolkit was to allow people to build custom tools that enabled migration and synchronization with other version control and work-tracking systems. The original release of the toolkit received a lot of negative feedback, and not many people were able to successfully use it.

In 2008, the product team made a decision to invest in an effort to address the feedback from the previous version and build a solid platform that enabled synchronization with other systems. The result of this effort is Team Foundation Server Integration Tools, which was released in the Visual Studio Gallery at http://aka.ms/TFSIntegrationPlatform. The Integration Tools are fully supported by Microsoft Support, and they are the same tools that Microsoft uses internally to keep data synchronized between different Team Foundation Server instances.

The platform uses adapter architecture, and it ships with a Software Development Kit (SDK) that allows others to implement the interfaces and leverage all the capabilities of the platform. The first adapters written were the work item tracking and version control adapters for Team Foundation Server 2008 and 2010. The selfish reason the product group invested in the platform was that they had a desire to start using early builds of Team Foundation Server 2010 for day-to-day usage. The problem with this was that the server code was not yet stable enough to risk upgrading the entire developer division's main Team Foundation Server environment. This prompted the team to set up a second server and run a two-way synchronization of work items and source code between them.

This not only allowed the team to be confident in the quality of Team Foundation Server 2010 before shipping it, but it also allowed the Integration Tools team to test drive their solution to drive features and improvements into the product. The end result is a proven and versatile tool for migration and synchronization of other systems with Team Foundation Server.

Warning

If you choose to use the Team Foundation Integration Tools, be aware that it is not often an easy path to take. Microsoft uses the tools internally with the latest versions of Team Foundation Server, so you can be relatively confident the tool will work in most cases, but there is likely to be a lot of hand-holding to ensure mirroring happens smoothly.

Unless absolutely required, we advise you avoid mirroring entirely.

Capabilities

In the first release, the built-in Team Foundation Server 2008 and 2010 adapters had the following capabilities:

· Synchronization—This included unidirectional or bidirectional synchronization.

· Version control—This included the migration of all files and folders and support for preserving changeset contents. The following change types are currently supported: add, edit, rename, delete, branch, merge, and type.

· Work item tracking—This included the migration of all work item revisions, fields, attachments, areas and iterations, and links (including links to changesets).

· Context synchronization—The tool can synchronize work item types, group memberships, and global lists.

Field Maps, Value Maps, and User Maps

When synchronizing two different systems, you are almost guaranteed that the configuration will be different between the two endpoints. This is where mappings are useful. As an example, you might have a Priority field with values 1, 2, and 3 on one side and valuesA, B, and C on the other. By defining a field map and associating it with a value map, the tool can seamlessly translate values back and forth when updates occur.

Another powerful capability is user maps. As an example, this is useful when you are synchronizing Team Foundation Server (which uses Active Directory for authentication) with a system that uses its own store of built-in user names. The user-mapping functionality allows you to map one system to the other.

Intelligent Conflict Resolution

In any type of synchronization, there will always be problems that you can't anticipate and automatically handle. Following are some examples:

· Someone changes the same field on both sides at the same time (an “edit/edit conflict”).

· One endpoint encounters an error and the update can't be saved.

· Permissions are insufficient for making an update.

· An attachment from one side is larger than the limit on the other side.

· A field can't be renamed because the new name already exists.

In all of these cases, the tool will raise a conflict that requires manual intervention. Depending on the type of conflict, the tool may stop processing more changes, or if the changes don't depend on each other, it will continue processing others.

The conflict-resolution process allows you to resolve conflicts and give the resolution a “scope.” For example, you can say, “Whenever an edit/edit conflict occurs, always choose the changes from the left endpoint.” Over time, the system is given rules, and the number of new conflicts to resolve is reduced.

Health Monitoring

When you install the Team Foundation Server Integration Tools, two reports get copied to your machine. To make use of these reports, you can follow the included instructions on how to set up the data sources and upload the reports. Once they are running, they will show you two things:

· Latency

· Conflicts

If people depend on synchronization for their day-to-day work, then you will want to make the reports available to users. You can also set up a data-driven subscription to e-mail you the report when latency exceeds a specific threshold. For example, at Microsoft, each of the synchronizations has a data-driven subscription that checks every 30 minutes to see if any endpoint is more than 30 minutes out of date. When one of them is, then it e-mails that report to the synchronization owner to alert him or her of the situation.

Following are the three most common reasons that an endpoint will be out of date:

· Someone has made a bulk update to hundreds of work items, and the mirror is still synchronizing the backlog.

· In version control, a conflict will block the processing of future changes, because it's not valid to skip mirroring a changeset and continue on.

· The mirror is not running for some reason. This can happen if the service stops, the machine running the service loses connectivity, or the password changes.

Each of these conditions can be detected by a subscription to the latency report and the conflicts report.

Examples

Team Foundation Server Integration Tools include a number of templates to get started, but the following are some of the most common uses.

Version Control Two-Way Synchronization to a Second Server

Take a look at the following snippet from a version control session configuration:

<FilterPair>

<FilterItem MigrationSourceUniqueId=”1f87ff05-2e09-49c8-9e9b-0ac6db9dd595”

FilterString=”$/Project1/Main”

MergeScope=”$/Project1/Main” />

<FilterItem MigrationSourceUniqueId=”8c85d8eb-f3b3-4f05-b8dc-c0ab823f1a44”

FilterString=”$/Project1/Main”

MergeScope=”$/Project1/Main” />

</FilterPair>

In this scenario, you configure a left and right migration source and provide two version control paths that you want to keep synchronized. It is possible to provide multiple paths, as well as different paths. The tool will translate the paths between the two endpoints.

You should always choose the smallest mapping possible because the more changes that must be processed the more likely it is to fall behind and get out of sync. If people are working on the same code in the two different locations, it's often a good idea to mirror into a branch of the code. That way, you can control when and how the changes from the remote server get merged into the main branch on the other side.

Work Item Synchronization to a Different Process Template

An outsourced development team may use a different process template than the in-house development team. This will cause a mismatch in the fields and values used to describe bugs, tasks, and other work items. Both organizations may have very valid reasons for using their own templates, and that's fine.

To accommodate this mismatch, the Team Foundation Server Integration Tools can be configured to map the different types to their closest equivalents. The following snippet from a session configuration file shows how a field can be mapped using a value map:

<WITSessionCustomSetting >

<Settings />

<WorkItemTypes>

<WorkItemType LeftWorkItemTypeName=”Bug”

RightWorkItemTypeName=”Defect”

fieldMap=”BugToDefectFieldMap” />

</WorkItemTypes>

<FieldMaps>

<FieldMap name=”BugToDefectFieldMap”>

<MappedFields>

<MappedField MapFromSide=”Left”

LeftName=”*”

RightName=”*” />

<MappedField MapFromSide=”Left”

LeftName=”Microsoft.VSTS.Common.Priority”

RightName=”Company.Priority”

valueMap=”PriorityValueMap” />

</MappedFields>

</FieldMap>

</FieldMaps>

<ValueMaps>

<ValueMap name=”PriorityValueMap”>

<Value LeftValue=”1” RightValue=”A” />

<Value LeftValue=”2” RightValue=”B” />

<Value LeftValue=”3” RightValue=”C” />

</ValueMap>

</ValueMaps>

</WITSessionCustomSetting>

Working Offline

In a geographically distributed team, you sometimes need to work offline. There may be connectivity problems between your client and the server, or the server could just be offline for maintenance. In any case, you can take measures to stay productive while you are working offline.

Version Control

If your solution file is bound to Team Foundation Server using Team Foundation Version Control, Visual Studio 2008, 2010, 2012, and 2013 will attempt to connect to the server when you attempt to open the solution. If the server is unavailable for some reason, the solution will be opened in “offline mode.” This allows you to continue working on your code while you are disconnected from the server.

Team Foundation Server 2012 introduced the concept of Local Workspaces, as discussed in Chapter 6. This feature better supports working offline and disconnection from the server because the items in your workspace are not marked with the read-only flag. You can continue to work with most operations, even undo pending changes, without needing to be connected to the server. Once the server is available, each of the pending changes is discovered automatically on the next file scan.

However, if you are using the legacy server workspaces or an earlier version of Visual Studio, a Visual Studio solution will remain offline until it is explicitly taken online. Once the server is available again, you can click Go Online in Solution Explorer and the connection with the server will be attempted again. Alternatively, you can open the solution and, when the server is available, go online.

With server workspaces, when you go online again, Visual Studio will scan your workspace for writable files, and then check out the files and pend the changes that you made while you were working offline. If you don't do this, and you perform a “Get Latest,” there is a chance you may overwrite your offline work, because the server doesn't know which changes you made while you were offline.

If you are planning to use this functionality in server workspaces, you must follow very specific instructions:

· When in offline mode, remove the read-only flag on the files you want to edit. You will need to do this from within Windows Explorer, not within Visual Studio. When you try to save a file that you haven't yet checked out, the file will be read-only, and Visual Studio will prompt you to see if you want to overwrite the file. This will unset the read-only flag and overwrite the contents.

· Don't rename files while offline. Team Foundation Server will not know the difference between a renamed file and a new file.

· When you are ready to connect to the server again, before doing anything else, run the online tool and check in the pending changes that it generates. That way, there will be no confusion between the new online work you will be doing and your offline work. If you don't do this, and you perform a “Get Latest,” there is a chance you may overwrite your offline work because the server doesn't know which changes you made.

For these reasons, we highly recommend that you consider using Local Workspaces instead of the traditional server workspaces, and that you use Visual Studio 2013 or Team Explorer Everywhere 2013.

Forcing Offline

If the connection to the server is slow or unreliable, it may be desirable to mark the Team Foundation Server as offline and disable auto reconnect on startup, so that you don't have to wait for it to time out. To do this, you need to have the Team Foundation Server Power Tools installed. Once you have them installed, you can follow these steps:

1. Open a Developer Command Prompt for Visual Studio 2013.

2. Type the following:

tfpt.exe connections

3. Once the TFS Connections dialog box is displayed, as shown in Figure 28.2, select your server, expand the node, and select the collection.

Figure 28.2 TFS Connections dialog box

4. Click Edit.

5. Clear the “Automatically reconnect to last server on startup” check box.

6. Select the Server Is Offline check box.

7. Click OK.

8. Close the dialog box.

Now, when you open your solution, it will be marked offline until you click the Go Online button and connect to Team Foundation Server.

Work Items

The intended way to work offline with work items is to use the Microsoft Office Excel and Microsoft Office Project integration installed with the Team Explorer client. With this integration, work items can be exported into a worksheet and saved to your machine for working offline. When you are ready to connect to the server again, the changes can be published back to the server. There is a limitation while working offline that prevents you from creating links to work items and creating attachments.

Additionally, the third-party tool, TeamCompanion from Ekobit, provides an Outlook add-in that also caches work item query results and allows for viewing and editing that data while offline.

Note

For more information, see the “Work Offline and Reconnect to Team Foundation Server” article on MSDN at http://aka.ms/TFSWorkOffline.

Other Considerations

Several other considerations can make the experience of working with geographically distributed teams better.

Maintenance Windows and Time Zones

The default Team Foundation Server installation will schedule optimization and cleanup jobs to start at 3 a.m. UTC time. This time means that these jobs run in the evening in North America, early morning in Europe, and in the middle of the day in Asia.

One of the benefits of Team Foundation Server is that you typically don't need the expertise of a database administrator or any extra SQL maintenance plans (beyond backups) to keep it reasonably healthy. To see how some jobs are affected, and perhaps change their schedules accordingly, see Table 28.2.

Note

For a full list of jobs that run across the configuration and collection databases and their schedules, see Grant Holliday's post at http://tinyurl.com/TFSJobSchedule.

Table 28.2 Built-In Server and Collection-Level Jobs

Online Index Operations with SQL Server Enterprise

When the Optimize Databases job is running for each collection, it may cause blocking and slow performance for some version control commands. If you have users around the world, and you have large indexes, there may be no ideal time for this job to run. In this case, you may want to consider upgrading SQL Server to an edition that supports online index operations.

The full version of Team Foundation Server 2013 includes a restricted-use license for SQL Server 2013 Standard Edition. Team Foundation Server 2013 Express includes SQL 2012 Express. If you license the Enterprise or Data Center edition separately for your data tier server, then Team Foundation Server will automatically make use of the online index operations available in these editions, which will prevent the blocking and slow performance that is typical with indexing operations that are not online.

Distributed Application Tiers

In Team Foundation Server 2008, it was possible to install Team System Web Access on a separate server than your main application tier. In Team Foundation Server 2010, 2012, and 2013, this is no longer possible because Web Access is now integrated into the server itself.

In the 2012 and 2013 versions, it is not supported and highly not recommended to have application tiers distributed away from your data tier servers. They should be on the same server (for a single-server installation) or in the same data center (for a multiple-server installation).

For version control operations, the architecture of the system is such that the application tier will request all the data that the user specified and then discard the results that it doesn't need or that the user doesn't have access to. This is because permission evaluation is done on the application tier.

These are just some of the reasons why Team Foundation Server 2013 does not support having application tiers distributed away from data tiers. It is very important to follow this advice because customers have experienced major issues with non-supported configurations and topologies by not following this guidance.

If your goal is for higher availability and spreading out the load across multiple application tiers, you can refer to Chapter 22, which discusses scalability and high availability.

SQL Mirroring

SQL mirroring involves synchronizing the data on one server with a copy of that data on another server. The limitation of mirroring is that it allows only one server (the principal) to be active at a time. The mirrored server cannot be used until the mirror is failed over, and the application tiers are configured to use the new principal server.

Because of this limitation, mirroring and technologies such as SQL AlwaysOn are useful only in a disaster-recovery or high-availability situation, rather than a geographically distributed team situation.

Summary

This chapter explored what it means to work with a geographically distributed team using Team Foundation Server 2013. You learned about some challenges, and then explored some of the solutions to overcome those challenges. You looked at Team Foundation Server Proxy in detail, and you learned about the potential of mirroring between servers with the Team Foundation Server Integration Tools. Finally, you looked at strategies for working offline while disconnected from the server.

Chapter 29 describes extensibility best practices, as well as all the different ways that Team Foundation Server can be extended through custom plug-ins and tools.