Team Foundation Server on Azure: First impressions

Team Foundation Service, the hosted TFS service on Azure, together with Visual Studio 11, has now provided much of the functionality that was missing from the previous incarnation of TFS. Bahadir gives a summary of the new features as seen in the test service, and demonstrates why they are so useful for team-based development

At the ‘Build Windows 2011’ conference in Anaheim, California, many new Microsoft products were announced in the Keynote presentations, notably Windows 8 and Visual Studio 11. For me though, the introduction of the Team Foundation Service (also known as ‘Team Foundation Server on Azure’ or ‘TFS Service’) was the most exciting new product by far.

Finally, TFS on Azure has become a reality. On the second day of the conference an invitation for TFS on Azure was given to all of the attendees. Most of the interested people like me who couldn’t be there had to wait an extra two hours while Brian Harry posted a new blog and issued two hundred and fifty more invitations for TFS on Azure. Fortunately I managed to wrangle an invitation which gave me a chance to look more closely at this new product.

Creating a TFS Service Account and Using the New Web Access

I followed the directions Brian Harry explained in detail in his blog post on how to create an account for this test service and started to use the new Web Access. First, you need to sign in to TFS. As you may know, previously the TFS Service users had to authenticate TFS via their Active Directory accounts; now we are able to authenticate using a Windows Live ID. Additional routes to authentication may become available in the future.

After I signed in, I created a new test project named AzureTest with the CMMI 6.0 (Preview) Process Template. Below is the home page of TFS Service Web Access, but as you can see there is only one team project so far.


This new web access is very important for your account because you have control over users, areas, iterations, user rights, source control and work items from this web site. There are two modes of usage, Administration and Normal. When you are in Administration mode, you can configure your team project items such as members, security, areas or iterations, but when you are in Normal mode you use the web site as a normal TFS client. This is an example of Normal mode:


… and Administration mode looks like this:


Just to reiterate, you can find more details about Web Access at Brian Harry’s blog post.

Connecting To TFS Service From Visual Studio

One great advantage here is that you don’t need to have Visual Studio 11 to connect to the TFS Service. Microsoft now lets you connect from your current Visual Studio 2010 and any other clients via Visual Studio 2011 Team Explorer Preview. Before you can achieve this though, you’ll have to download a client patch. If you want to connect to the TFS Service via Eclipse or any other clients you have to download Team Explorer Everywhere.

In this article I want to focus on the new Visual Studio 11 Developer Preview and TFS Service. Currently Visual Studio 11 Developer Preview can be downloaded from here. After you install and open Visual Studio 11,  you’ll see the usual Start Page. At this point, click Connect To Team Foundation Server at the left side of start page.


After you click Connect To Team Foundation Server, the usual Connect To Team Project window appears. The first difference you’ll notice after you add the TFS Service is the Sign-In Team Foundation Server window as can be seen below.


You can sign in with your Windows Live ID; when click the button you’ll be redirected to a sign-in page. Once you have successfully signed in, Visual Studio 11 connects to the TFS Service.

New Team Explorer Window

Team Explorer is the most significant change in Visual Studio 11 to accommodate TFS and is your new central point for TFS jobs. In earlier versions of Visual Studio, there was a Pending Changes window beside Team Explorer and you had to use both of them to use TFS. But with TFS 11 (and, of course, TFS Service as well), Pending Changes  has moved into Team Explorer.

These aren’t the only changes to Team Explorer. Since it has been created from the ground up, there is a whole new Team Explorer window which looks like this:


At the top of window, you can see the standard toolbar which lets you navigate between pages. Below this toolbar you can see name of the currently connected team project and a down arrow. Clicking the down arrow opens a menu which lets you select another team project or create a new project.

The page currently open is the Home page, you can access the main views from here. We’ll now look more closely at some other views.

My Work


My Work is a new area for Visual Studio users where you can organize your work using work Items. For example, in the To Do section all of the work items assigned to you are listed. Above the To Do section there is an In Progress section which contains your active work items. You can add work items here by right clicking on Work Items in the To Do section or by clicking Add Work Item by ID in the In Progress section.


I expected the work item’s status to change to active when I added it to the In Progress section; but it doesn’t appear to update automatically. I’m not sure whether or not this is a bug.

There are various other actions that you can perform on work items here. When you click the Finish link your pending changes will be checked in, but your work item doesn’t appear to automatically update to a new logical workflow state.

You can also perform a Suspend action. Sometimes in real life you get surprises which disrupt your workflow. Imagine you are working on a task when a critical bug presents itself. At this point, you need to suspend your current work and move to tackle the critical task. You had two options to deal with this in earlier versions of TFS. The first option was using a fresh workspace; the second option was shelving your current pending changes and starting work on the new task. In TFS 11, you have a new option, suspend your work. This is another way to shelve work, but is much easier.

You can also add more work items to the In Progress section through the More action.

Pending Changes


I’ve already mentioned that the Pending Changes window is integrated into Team Explorer. This new Pending Changes view is much easier to use than the old one and is split into four sections. The first one is a Comment section as in earlier versions. The second section is called Related Work Items. In this section, the work items which are listed will be associated with your changeset when you check-in. By default, those work items that are found in the In Progress section of the My Work view are listed.

The third section of this view is Pending Changes. Currently I have no pending changes so there is nothing in the list. But if I edit some of files, then I can populate this section. Let’s try this out:


As you can see, this file appears within the Included Changes section. Before Visual Studio 11, when you wanted to edit a file that was under source control, you had to check-out that file from Visual Studio first, and then edit it. With Visual Studio 11, you can skip that step. The files under source control are no longer read-only, so you can edit them directly from outside Visual Studio 11. When no longer read-only, so you can edit them directly from outside Visual Studio 11. When you do this, Visual Studio automatically detects what’s going on and marks the file as being checked-out. Another big improvement is offline working. When you are working while disconnected from TFS and you modify a file, Visual Studio automatically detects this and marks it as checked-out. Neat.

You might ask at this point, where are the checkboxes? In earlier versions you had to check the checkboxes of the members of the file-list that you want to check-in. But, in this version there is no checkbox; we have an Excluded Changes section instead. If you want to exclude a file from check-in, you have to move that file from the Included Changes section to the fourth section called Excluded Changes.

If we turn back to the top of window we can see the Check-in button for checking files into TFS. Near the button there is Shelve link, if you click this, the usual Shelve windows will appear. Near the Shelve link, there is a More menu link. Clicking this will open a new menu where you can find other actions such as, Find Shelvesets, Get All Conflicts, Undo All, Request Review (this will be detailed later) and finally, Settings.

You can find more information about this subject in Brian Harry’s blog post.

Work Items


This view looks like the previous version. You can find New Work Item link and Work Items -> Queries in this view. There are no important changes here, but the work item forms have changed, so let’s look them more closely.

New Work Item Forms


From this image you can see that this is all very different from the previous versions. If you look carefully, some of the words may look a bit funny; this is likely caused by my regional settings being set to Turkish and I reckon it’s a non-critical bug. Another thing to notice is we finally get a rich text Description field.


In this screenshot, the Requirement work item is shown and is rather different to the Task type. The design has changed but the individual fields haven’t.




Builds is a new view. Build definitions can be found here, and new build definitions can be defined from here also. In this test TFS Service, there is no default build controller available and I haven’t installed a build agent on my computer yet so I couldn’t try it out. I am planning to write about this soon with another Team Foundation Server 11 Preview article.



Settings view contains links for general settings. An array of links is presented to allow web access to operations such as Security, Group Membership, Work Item Areas, and Work Item Iterations. Some of these open familiar windows such as Source Control, Portal Settings, and Process Template Manager.

Compare and Merge

In previous versions of TFS, comparing and merging was a big problem. The Compare window hadn’t changed since VSS, until now. Let’s take a closer look:


The Compare window has more than one mode to compare, and the default setting is Inline mode. In this mode a red-highlighted line means source version, a yellow-highlighted line means target version. Main changes are marked as a red-lined square. If you want to see a more familiar mode you can look at the Side By Side mode.


The Side By Side mode probably looks more familiar but actually it’s very different from previous versions: Now it is not just gray screen, it’ the usual coding view. You can see line numbers, highlights for keywords, or combo boxes for navigating in code. As shown above, there is a little bug at the top of compare window. File paths are in mesh.

There are two more modes, Left file only and Right file only. These modes only show the selected part of compare screen.

If you look carefully, you can see a new mini toolbar shown when the Compare window is active, so let’s look this new toolbar more closely:


In this mini toolbar there are four buttons. The first one is the mode-changing button to change between the comparison modes I described above. The second and third buttons let you navigate between differences. The last button lets you ignore whitespace while comparing. You can find more information about Merge and Compare at Brian Harry’s blog post.

Code Review Workflow

Visual Studio 11 has another new feature called the Code Review Workflow. Code reviewing is a very important process for development teams, but there didn’t used to be one single tool that suited every requirement. Microsoft has finally developed an integrated solution for this workflow and integrated it into Visual Studio 11. Let’s look at this new special workflow.

For this example, I modified a form and went to request a code-review from my colleague. I needed to open the Pending Changes view in Team Explorer window and clicked More -> Request Review.


After you click Request Review, a new Code Review view will be opened.


First, you have to enter your colleague’s name to do the review. In this example I have to enter my name because there is no user except me. If you wish, more than one name can be entered. After selecting the reviewer, you then have to enter a subject for this Code Review. The textbox below Review Name is for the Area Path. In this project there is only one Area Path so I don’t need to select anything as the only Area Path is selected by default. If you need to send a comment to the reviewer(s) you can enter this in the final textbox. As you can see, there are 3 modified files for review. If you are wondering which files are modified, you can click the View Changes link. Also, you can add related work items for this review in case the reviewer(s) need to check them.


When everything is completed, click the Submit Request button. After you submit your request, Visual Studio 11 creates a workflow by shelving your pending changes. When the reviewer opens his/her My Work view, your request is displayed as you can in the image below.


As you can see above, a new section had been added to the My Work view named Code Reviews & Requests. All of the incoming and outgoing requests are listed here; however you can filter by incoming requests or outgoing requests. If you want, you can see your requests from Work Item Query. You have to double-click a request to open it. 


All details of requests are shown like the one above. What is the title of the request? Who had requested it? There is a list of reviewers, related work items, comments and files had sent to review. If you want to see more details about the shelveset or wish to unshelve the shelveset you can click the View Shelveset link.


To review codes, you can click files. When you click, Visual Studio opens the file within the compare mode, so you can see what developer had changed.


If you have any comments, you can click the Comment link beside the file name and then enter your comment into the opened textbox.


Maybe you want to reply to the developer’s comment? You can click the Reply link below the comment.


After you complete the review, you should click the Close Review link at the bottom of the Code Review section. Now you have two options, Abandon or Complete.

Let’s turn back to the developer’s perspective. After the review is completed, you can see details at the Code Review -> Request work item. All code review requests create a work item.


The screen shot above shows the details of the abandoned review. The screen shot below shows the completed review’s details.


As you can see, the Code Review Workflow has been designed to be as useful as possible to the average development team.


I have tried to describe the new features of Visual Studio 11 and the TFS Service. In my opinion, even in the current version, the TFS 11 Developer Preview seems to be excellent, and it will only continue to improve in subsequent versions. I was particularly impressed by the new Team Explorer and was almost as excited by the Code Review Workflow too. I checked out the Test Manager 11 too, but I couldn’t find any major differences, so decided against describing it in this article.

I am planning to write another article that focuses more on Team Foundation Server 11, so look out for my new article because I saved several details for use later.

If want to download and try Visual Studio 11 Developer Preview for yourself click here and download.

Bahadir has also written a review of the providers of Hosted Team Foundation Server 2010