第 161 页

sure you are getting the exact labeled version, you will probably choose to overwrite writable fi les.

You should undo, shelve, or check - in any pending changes before getting a specifi c

version to separate the latest changes in your workspace from the labeled version.

fiGure 57 - 17 fiGure 57 - 18

Version Control .

1125

If you want to get the version in a different location, you can create a branch. You see this later

in the chapter.

history

Every change you make is persisted in the server and you can get to any specific version of a file;

a great way to do it is through the History window. Simply right-click a file in Source Control or

Solution Explorer and select View History. From there you can see how a file has evolved over time

(Figure 57-19). When you right-click any version, you can compare it to your version, open it, and

view details of the changeset (including the comments and related work items).

fiGure 57-19

Toward the top of Figure 57-19 is a tab to switch

between Changesets and Labels. Switching to

Labels view, shown in Figure 57-20, displays a

list of all of the labels that have been applied to

the file. This can be very useful to quickly see all

of the changes made between two versions.

annotate

The annotate command enables you see when

and who edited each line of code (Figure 57-21).

From each of the changes made, you can get to

each particular changeset to see details, get that

particular version, compare it to its previous

version, locate the file in the History window, or

annotate from that version.

shelve

When you check in a file, that change is

automatically made available to others.

Sometimes you need to persist your changes

without affecting everyone — a scenario

that can happen when you need to work

from another computer and want to upload

fiGure 57-20

fiGure 57-21

1126 .

chaPter 57 TeAm FoundATion SerVer

your changes and send them somewhere else, or when you are in the middle of something and are

assigned a new task.

Shelving persists your changes in the server. You can associate a shelveset to work items and add

comments and check-in notes, much as you would when checking in. You can optionally evaluate

check-in policies before shelving and choose to undo local changes after the shelve is done. The

latter is useful when you need to work on some other work item without the shelved changes

interfering with what you are doing. Shelving changes is also useful if you are moving to another

machine and don’t want to have to make the same change in both places. To get to the changes, you

can unshelve your shelveset and your files will be checked out again.

Each shelveset is a read - only snapshot of the fi les at the time when it was created. Because of this,

each shelveset is not versioned and if you save a new shelveset with the same name as an existing one

it will simply overwrite it. This can be extremely handy for common tasks such a Work In Progress or

For Review.

Shelvesets are uniquely identified by a combination of their name and the name of

the user who created them, so even if you use the same naming scheme for your

shelvesets as another team member you won ’t be able to overwrite each other ’s work.

Although the default behavior is for you to see the shelvesets that you have created, you can see the

shelvesets that other people have created and even retrieve them, which can be useful if you need a

colleague to review some code before it is checked in or to hand a task off to someone when it is not

in a state that is ready to be checked in.

There is an option hidden behind the Details when unshelving a shelveset to Preserve Shelveset

on Server. If you uncheck this option the shelveset is deleted from the server as you retrieve it. You

can also delete shelvesets without retrieving them from the Unshelve dialog. It is a good idea to

clean out shelvesets regularly that you don’t need any more to make it easier for you to find the ones

you actually use.

branch

A branch, in source control terms, is a parallel version of your code. This is useful for different

purposes. Here are a couple of examples:

.

Hot fixes or bugs for stable versions while working on new ones. When you release 1.0 you

label all your source code and start working on 2.0. Then a critical bug is found but version

2.0 is months away from being ready. You will branch from version 1.0 (you can get to this

version using the label). Then you can fix the bug in the new branch and release version 1.1.

Later you can merge the change made and integrate it with the main branch.

.

Creating a branch from the latest version to do a big refactoring or a change you are not

sure will work and thus don’t want to affect the main branch. If it works you can merge it

with the main branch and if it doesn’t you can simply delete it.

Version Control .

1127

You have to choose wisely what branching strategy is better for your organization, type of product,

and process, or when you could substitute by simply labeling a version or shelving a change. Abuse

of branching can exponentially complicate source-code management. Codeplex hosts branching

guidance that provides additional scenarios (http://www.codeplex.com/TFSBranchingGuideII).

To create a new branch, right-click the folder you want to branch from and select Branching and

Merging . Branch. You will be asked which version you want to branch from and where the branch

should be saved in the source control repository.

Branches have become fi rst class features in TFS 2010 so the tools are able to take

full advantage of them. You can mark an existing folder as a branch by supplying

the required metadata, which allows branches from previous versions to take

advantage of this as well.

Once you have a few branches you can use the Branch Visualization (Figure 57-22) tool to see the

hierarchy of your branches by selecting View Hierarchy from the Branching and Merging drop-

down in the Source Control Explorer. You can initiate merges from this tool by dragging from one

branch to a valid target branch.

fiGure 57-22

Another new tool in TFS 2010 is Changeset

Tracking, which allows you to see where

the changes in a particular changeset have

come from. It has two views: Timeline

Tracking (which is shown in Figure 57-23)

and Hierarchy Tracking, which shows the

hierarchy between the branches in a clearer

fashion. Just as with the Branch Visualization

view, you can initiate a merge by dragging a

changeset from one branch to another. fiGure 57-23

1128 .

chaPter 57 TeAm FoundATion SerVer

Merge

If you fix a bug or implement a feature in one branch, it would be advantageous to be able to apply

that same changeset to other branches. This is what the merge operation does. To begin a merge,

right-click the folder or file you want to merge and select Branching and Merging . Merge. Once

you have selected a source and destination for the merge, you are presented with a list of changesets

that that can be applied. Select the changesets that you want and click Finish. If there are any

conflicts, you will be given the opportunity to fix them.

teaM foundation build

Team Foundation Build is a tool, part of TFS, and its responsibility is to get the latest version from

source control to a local workspace, build the projects as configured, run tests, do other tasks,

and finally report the results and leave the output in a shared folder. Each machine that is able to

build a project for you is called a build agent. TFS 2010

also introduces the concept of a build controller, which is

responsible for coordinating the activities of several build

agents. The information that each build agent needs to do

its job is called a build definition.

To create a new build definition, right-click the Builds

folder in Team Explorer and select New Build Definition

(Figure 57-24). In the General tab you need to write the

build name and optionally a description.

By default the build has to be manually queued, but in the Trigger tab you can modify this behavior.

You have five options, as shown in Figure 57-25. The new option for TFS 2010 is the Gated Check-in

option. When you have build definitions that are triggered this way, check-ins will not necessarily go

straight into source control. Instead they will be shelved (you will be prompted about this) and built

by a build agent first. If the build succeeds, the shelveset is saved into the source control repository. If

it does not, you are notified and it is up to you to retrieve the shelveset, make any required changes,

and check it in again. Using this type of build definition prevents the situation where the contents of

the source control repository do not compile, which can significantly impact the rest of the team.

fiGure 57-24

fiGure 57-25

Team foundation Build .

1129

Depending on how big your project is, how long it takes to build and run the tests, and how often

the team checks in, this option may cause some overhead. The third option, Rolling Builds, will

definitely help alleviate the workload, but it’s better to wait until you find you need it.

Configuring the workspace will be used in complex scenarios where you have dependencies between

team projects, so the defaults in that tab might be enough. In the build defaults page, you can choose

a build controller and a shared folder to drop the output into. These will be used for triggered

builds, but for manual builds this can be overridden.

The Process tab, shown in Figure 57-26, allows you to configure the build process. Here you must

select at least one project or solution and a configuration (like x86|Debug or AnyCPU|Release).

The rest of the values are optional but include information allowing you to specify the location of

any automated test assemblies, whether or not to perform code analysis, if the build agent should

publish the project symbols anywhere, how to format the build number, and more.

fiGure 57-26

TFS 2010 build processes are based on a process template that is defined with Windows Workflow 4.0.

You can create your own custom process template by copying the default one and making changes

to it. A number of custom activities are related to Team Build and you can always create your own.

If you have a build defi nition from a previous version of Team Build you should use the Upgrade

Template, which only requires a path that contains the legacy TfsBuild.proj fi le.

By default the build process templates are located in the $/TeamProjectName/

BuildProcessTemplates folder in the source control repository.

1130 .

chaPter 57 TeAm FoundATion SerVer

The retention policy lets you choose how many of the builds left in the shared folder will be kept before

some are deleted. It is recommended to use the Keep All option, at least for successful builds, until you

need to reduce the number of files being kept around. There are two sets of settings. The ones under

Private relate to builds that form a part of a gated check - in and are not as important to keep around.

To start a build manually, you can right-click the Builds node in the Team Explorer and select Queue

New Build. Once the build is queued you can open it by double-clicking it in the Build Explorer.

This opens the new Build Report, which has been greatly improved from the previous version. This

report, shown in Figure 57-27, includes information on current activity, previous build statuses and

durations, and provides links to a number of other areas and activities related to this build.

fiGure 57-27

If you want to be notifi ed of build events while you work, there is a Build

Notifi cations system tray application that is installed with Team Explorer. Once

confi gured, this application will adjust its icon based on whether any builds you

are watching are broken, building, or if everything is built successfully.

rePortinG and business intelliGence

TFS uses Report Server, which is part of Microsoft SQL Server, to provide useful information

for project managers, customers, and developers. Reports can be accessed directly from Team

Explorer, the reports site (http://mytfs/reports/), SharePoint, or Team System Web Access,

reporting and Business intelligence .

1131

or they can be configured as a subscription from the Reports site to be left in a Windows file share

or sent through e-mail.

The great benefit these have is that developers can focus on their work instead of manually filling

out reports. All the information is collected during their daily work, checking out and checking in

code, fixing bugs, and relating what they are doing to work items. This way project managers and

stakeholders can get to the information they need from the reports TFS provides.

Each process template provides its own set of reports. The CMMI version provides three additional

reports and templates like Scrum for Team System from Conchango, and has reports appropriate for

the Scrum methodology like Delta Report and Burndown Charts. Again, we will focus on MSF for

Agile Development here.

Some of the reports included are Burndown and Burn Rate, Stories Progress, Build Success Over

Time, Build Quality Indicators, Test Case Readiness, Test Plan Progress, Bug Status, Bug Trends,

and Reactivations. Figure 57-28 shows how the work has been resolved over a couple of years and

how much work is left. In the report you can filter by dates, work item type, iteration, and area. You

can export to XML, CSV, TIFF, PDF, Web, and Excel.

You don’t need two years of information to get useful reports. Depending on the nature of the data

displayed, you might not see anything at the beginning. For example, the Test Failing reports will

need to have at least one test in your team build process, or to have data for the Regressions report

you need Passing tests that are now failing. Similarly, the Scenarios Details report will need you to

register at least a Scenario Work Item. After a couple of iterations of working with TFS you will

have a lot of useful metrics for free.