第 160 页

a bug and also create a link between it and the

selected test. You can navigate from the bug

to the test or see the test and its related work

fiGure 57-7

items (Figure 57-7). If the test fails again, you

can see the work items associated with it and track it back to their related change sets, as you will see

later in the “Version Control” section. Visual Studio 2010 is able to associate IntelliTrace information

with the work item; that way the developer assigned to correct the bug can easily reproduce it.

Each work item can be related to many others with links. Team Foundation Server 2010

understands several different types of links, including Parent, Child, Predecessor, and Successor. To

add a link, click the All Links tab and click the Link To button. You can also create a new work

item directly linked to the current one with the New Linked Work Item button.

work item state

During your normal daily activity, you will be working on tasks that are described by work items

that are assigned to you. Each work item is described by a simple state machine that determines the

allowed new states for any given state. This state machine is a part of the work item definition and

is decided by the process template. Whenever a new state is selected you can provide a reason for the

excel and Project integration .

1117

state transition. For example, the Bug work item in MSF for Agile can go from Active to Resolved to

Closed. It can then go back to Active again with a reason of Regression or Reactivated. The reason

field allows you to differentiate between the bugs that are active because they are new and those that

are active because they have re-occurred.

excel and ProJect inteGration

Looking at, adding, or editing work items can get a bit complicated and won’t scale well when you

have hundreds of tasks. This can be problematic especially for project managers who are not used to

working inside Visual Studio. They usually prefer to work from Excel or Project. This integration is

really easy using the provided add-ins.

excel

From the Ribbon, simply click New List and choose a Team Project and Work Item Query. This will

retrieve all the information from a web service and display it in Excel. Once it’s there you can sort,

filter, edit, and publish changes back to the server, refresh the changes made by others, add links or

attachments, and choose columns to be displayed.

Another way of doing this is from Team Explorer. From a work item query’s context menu, select

Open in Microsoft Excel. This will create a new Excel worksheet with the information. Figure 57-8

shows both options and Figure 57-9 shows the results in Excel.

fiGure 57-8

1118 .

chaPter 57 TeAm FoundATion SerVer

fiGure 57-9

The MSF for Agile template creates a number of standard work item Excel workbooks, which are

hosted on the SharePoint Portal. These are found in the Documents node under Excel Reports.

Project

There is also an add-in for Project. Similar to

when you use Excel, you can connect to a server,

choose a team project, and select a work item

query, but instead of using the entire list, you

have to choose each of the work items you

want to import to your project, as shown in

Figure 57-10.

Once your work items are imported, you can

edit each of their fields directly in Project. This

is possible thanks to the column mappings

between TFS fields and MS Project Columns.

For example, Resource Names in Project will

map to the Assigned To field in TFS. Fields

that exist only in Team System will be mapped

to Text Fields in Project; for example, Work

Item Type is mapped to Text 24. This is preconfigured in the process template.

You can add new work items, nest them in iterations or areas, assign them to people, choose a work

item type, balance workloads between resources, see project reports, and refresh the progress from

the server after each developer changes the work remaining or work item state.

Unlike the previous version of TFS, the 2010 edition does understand the notions of hierarchical work

items and successor and predecessor tasks. When the work items are loaded into Project, it is able to

take advantage of these links to create a normal Project experience. As new associations are created and

updated, Project is even able to return the updated data to TFS in a form it can understand.

Important differences still exist that make the integration a bit tricky:

.

In Project you can have many resources for the same activity, but TFS only accepts one

entry. One approach could be to add a custom field to the work item type, but then the

fiGure 57-10

Version Control .

1119

mapping won’t work because you would need to have one column in Project mapped to two

fields in TFS. The workaround is to add the activity once for each resource.

.

There’s no Project server/TFS integration out of the box. A couple of third-party tools are

available that do this for you. The next version of Team System will include it, as well as

project management improvement across multiple projects for load balancing of resources.

If you are going to use Project with TFS you should look at the article “Quick

Tips and Operational Differences when Tracking Tasks using Office Project

and Team Foundation” on MSDN at http://msdn.microsoft.com/en-us/

library/dd380701(VS.100).aspx.

Version control

Version Control (sometimes called Source Control) is a tool that allows you to manage, share, and

retain a history of changes to your source code. To interact with the TFS version control system, you

use the Source Control Explorer window, shown in Figure 57-11. You can open this window from

the Team Explorer window or View . Other Windows . Source Control Explorer.

fiGure 57-11

1120 .

chaPter 57 TeAm FoundATion SerVer

To work with files on your machine, you will need a workspace that defines a set of mappings

between paths on your local file system and the remote system. You can define a different local

folder for each path, but a good practice is to have only one mapping; this helps keep all the

solutions and projects relative to each other even between different team projects. To define this

mapping, open the workspace combo box and select Workspace.

Once your workspace is set up, you can get the latest version of the source code and start working

with it, add files, check out files (mark as edit) or check in (upload/persist) changes, view change

history, and compare folders.

In previous versions of TFS, each workspace was limited to a single user on a

single machine. Visual Studio 2010 introduces the concept of a public workspace

that can be shared among multiple users on the same machine.

working from solution explorer

When you create a new project you have the option to add it to Source Control. Team System will

automatically bind it and add it according to the mapping previously defined. That’s why you need

to set the location to a folder inside your workspace (the local path you mapped to), as shown in

Figure 57 - 12.

fiGure 57-12

Version Control . 1121

The Solution Explorer you are used to working with in Visual Studio will be the main place to

interact with your source control system. Every time you add a new fi le to the solution, it will be

added to source control; when you open a fi le and VS detects you ’ re editing it, it will be automatically

checked out for you. Once you are done working, you can simply right - click the solution and choose

Check In to persist your changes in the server. See the section “ Source Control ” in Chapter 13 for

more information on the common tasks; this chapter explains the specifi cs of Source Control as it

relates to Team Foundation Server 2010.

Though it is common to work directly with TFS source control via the Solution

Explorer, this can have some disadvantages because it means that Visual Studio

is only able to manipulate the fi les that are referenced by your solution. If you

have other items in source control that are not part of your solution, you need

to manage these from the Source Control Explorer window.

check out

Files under source control are by default read - only; in TFS terms you would say the fi le is checked

in . To start editing a fi le you need to check it out. This is done for you automatically when you

modify it from VS. When the fi le is a text fi le (that is, a C#, VB, or XML fi le), the IDE will do

a shared check - out ; if it ’ s a binary fi le (that is, a Word document, SQL Server Compact Edition

Database, or another resource) an exclusive check - out will be made.

Shared check - outs allow two or more developers to modify a fi le at the same time, whereas an

exclusive check - out prevents a second developer from checking out the fi le. You can choose to do

an exclusive check - out on a text fi le if you need to prevent anyone from modifying it. This is not a

recommended practice, and you should only use it when you really need it. A good example of this

is when you are about to update the data for a WCF reference. This sort of information is textual,

but not easy to merge because many fi les are all updated at once. By using exclusive check - outs you

can ensure that no one else is modifying the reference at the same time as you.

If you install the TFS2010 Power Tools you can check fi les in and out directly

from Windows Explorer.

check in

To preserve your changes in the server, you will need to check in the edited fi les. You can select

which fi les to include in this changeset , add comments to it, associate it with work items, and add

check - in notes (Figure 57 - 13).

Depending on the policies defi ned for the team project, you might need to associate your check - in

with a work item, run code analysis, have it pass tests, or at least successfully build the solution. To

modify a team project ’ s policies, open the Source Control Settings window (Team . Team Project

Settings . Source Control) and go to the Check - in Policy tab. Once the policies are defi ned, you will

get Policy Warnings (Figure 57 - 14); these can be overridden.

1122 .

chaPter 57 TeAm FoundATion SerVer

fiGure 57-13 fiGure 57-14

You should check in a group of files related to a logical change at the same time

rather than one at a time. The set of files associated with a check-in along with

any notes and work item associations become a changeset. Changesets make

managing project history and merging much easier.

resolve conflicts

Although shared check-outs allow multiple developers to work on the same file, this can lead to

conflicts. These can easily be resolved with the help of Visual Studio. From the Pending Changes Conflicts

window (Figure 57-15) you can compare versions and look at all the changes to that file.

To resolve it, you can use Auto Merge and let Visual Studio merge the changes for you, undo your

local changes, discard server changes, or merge changes manually in the merge tool.

fiGure 57-15

When the changes were made in different parts of the file (for example, two different methods),

VS can automatically resolve changes, but if changes were made in the same line you have to either

choose a version or manually merge both files using the Merge Changes tool.

Version Control . 1123

In the Merge Changes tool (Figure 57 - 16), you will have a view of “ their ” version (that is, the server

version), your version, and a merged version. You can navigate easily between changes and confl icts.

In the case of confl icts, you can manually edit the offending lines or select a version to keep. When

all confl icts are resolved, you can accept the changes, keep the new fi le as your current version, and

proceed to check - in.

Visual Studio will compare text to determine if changes overlap, but this will not

guarantee the resulting fi le will even compile or behave as expected. This option

is really useful, but has to be used with caution. Over time, you will have more

confi dence in choosing which fi les to auto - merge to save time and which are worth

a quick look just to be sure.

After resolving confl icts, it is recommend that you run the automated tests again

to ensure there are no breaking changes. As you will see in the “ Team Foundation

Build ” section, this test can be run automatically in the server before each check - in,

but it ’ s best to get the feedback as early as possible.

fiGure 57 - 16

1124 . chaPter 57 TeAm FoundATion SerVer

working offl ine

Team Foundation Server uses HTTP and web services and can work perfectly through the Internet

and allow for collaboration of distributed teams, but in case you don ’ t have an available connection

VS will allow you to work offl ine when you try to open a bound project.

All fi les under Source Control are read - only. When you save a fi le you will be warned and should

simply choose Overwrite. When the connection with TFS can be reestablished, you can select to go

online from Solution Explorer or by right - clicking the solution. VS will look for fi les in the solution

without the read - only attribute; if those are not in Source Control it will add them, and if they exist it

will check them out.

Files modifi ed outside the solution won ’ t be detected and you have to manually

check them out. To make this easier, you can compare your local copy to the

latest version by right - clicking a folder in the Source Control Explorer.

label

Labeling a specifi c version allows you to refer to it easily. To create a label you simply right - click a

folder in Source Control Explorer that you want to mark, add additional fi les if necessary, and write

a Name and optionally a Comment (Figure 57 - 17). Similarly, you can get to a specifi c version using

the label. The perfect use for this is to release a version.

To get a labeled version, right - click a fi le or folder in Source Control Explorer and select Get Specifi c

Version from the context menu. On the Type combo box in the Get window (Figure 57 - 18) select

Label. You can search for labels by name, team project, and owner. Once you fi nd the label, to be