Back

TechnologyMay 28, 2013

What to Do When Team Foundation Service (TFS) is Down

Fernando Berrios

When cloud services go down while you’re working it’s common to feel a mix of rage and helplessness. The exact amount of each feeling depends on how close you are to your project’s deadline.

Finding ways to keep working during those kinds of outages is crucial to keeping your projects on track. We’ll explore how to do that with Microsoft’s Team Foundation Service.

TFS Improvements

About midway through last year Microsoft finally opened up their Team Foundation Service (TFS) Preview to the public, and ever since then the team behind it has been continually improving it and adding to its list of features. One of the most exciting features recently added to TFS was support for Git. Giving developers the alternative to choose one of the most popular open source Version Control Systems (VCS) over their own offering was a pretty bold move. They also stepped up their game by developing a plug-in for Visual Studio that adds support for Git, which works with any standard Git repository. As the kids say nowadays, no vendor lock-in is the bee’s knees.

So while Microsoft’s TFS offering is pretty good it is also subject to many of the same problems that any other piece of software has, mainly the fact that it will at some point stop working.

What Do You Do When TFS Is Down?

When TFS goes down the first step is to confirm that it’s actually down. Start by asking your colleagues and teammates if they are also affected.

Step two is confirmation/denial. I personally like to visit and refresh the TFS blog page and the twitters like a madman. Those sources will usually have information regarding any outages.

Step three is to calm down and work through it. With any luck the service will be back up soon.

Now you can probably live without the Application Lifecycle Management (ALM) features of TFS, but should you find yourself in a situation where you desperately need to check in some code or conversely need some of your team’s code in order to keep working on your current task, here are some things you can try:

Use a Backup Remote Repository

Every copy of a Git repository is ultimately a clone of each other. This means that you can quickly clone your local repository to a remote repository and start using it right away just as if you were using your “main” repository. This remote repository can be anything from an on-premise hosted repository to an external service (such as GitHub, BitBucket or countless others). You can even use a network shared folder that all your team members have access to.

It goes without saying that having this backup repository already in place and configured beforehand will speed up productivity during outages. You can also keep this mirror backup repository up to date by either setting up a scheduled task to periodically push to it or by updating both your main and backup repositories simultaneously on every push. Here is a sample of a simple batch file you can use to do the latter:

@echo off git push git push --mirror backup pause

Also make sure to first have your backup repository added as a remote in your working folder. You can do so by running this command:

git remote add backup <URL>/<Directory>

Of course if your project is using Team Foundation Version Control (TFVC) your options for having a backup repository will be a lot more limited. One reason for this is that there are a lot more options for cloud hosted Git repositories than for TFVC, but also because TFVC is not a Decentralized VCS (DVCS).

Use a Backup Local Repository

Another viable option if you are using Git is to create a clone of a local repository onto a portable hard drive or USB drive and pull/merge/push to and from it. If using TFVC, I suggest copying and pasting the updated files to the drive and updating your code base from there. Passing around this drive to each team member will have them back up and running the latest version of the code base in no time.

In order to create this backup local repository using Git you can run these commands:

1.  Navigate to your source directory (for the sake of a simple example let C:\ be your main drive and F:\ your portable):

 cd C:\path\to\your\repository

2.  Create the folder in your local backup drive and create a clone of the source repository there:

mkdir F:\path\to\backup git clone --local --no-hardlinks --bare . F:\path\to\backup\repository.git

3.  Then register the new backup repository as a remote repository in your working folder and push your branch to it:

git remote add backup file:///F:\path\to\backup\repository.git git push backup master

Email/IM Diff Patch Files

Another backup option which might be somewhat dated but effective (and probably unfamiliar to .NET developers) is the use of diff patch files. With this solution you will be able to create files that contain the difference between two files and allow you to re-create those same changes on remote copies of those same files. This is handy in situations where one developer has made change to a specific part of a file while another developer has made other changes in another part of the file. By creating a diff patch file and applying it, you can merge the two changes from both developers seamlessly.

To create and apply the patch you will need to download the Windows ports of Diff and Patch. Once you have these installed, it’s pretty easy to create a patch by running this command:

diff -u original.file new.file > original.patch

After that, you can apply the patch by running:

patch original.file original.patch

The patch files generated by the diff command are usually very small which makes them ideal for transferring via email or instant messaging clients.

Stay Productive When the Cloud Goes Down

So there are many different options that will allow you to stay productive when the big powerful cloud goes down. I was inspired to write this post while working on a project recently where a serious outage of TFS caused by an outage of the Microsoft Azure service left the team unable to check in or get the latest changes for almost the entire work day. Fortunately our productivity did not suffer since we were all working on isolated tasks, but your team might not be so lucky if it ever happens to you.

If you have TFS or ALM questions, please send them to us via the comment section below or tweet us @CrederaMSFT.