Team Foundation Server 2012 Starter

Start by running the installation (Setup.exe) from the TFS installation media. The installation itself just installs all the binaries; it doesn't require you to configure anything. It will install the .NET 4.5 Framework, which might require a machine restart as part of the installation.

The interesting things happen afterwards when you run the Configuration Center. This wizard launches automatically and lets you choose what kind of installation of TFS 2012 you want.

In the Configuration Center window, select the Basic option and press the Start Wizard button. On the Welcome page that follows, press Next.

Now, you need to choose which database server you want to use. You have the following two options:

If you already have an existing SQL Express instance on your machine, then the first option is disabled, as shown in the following screenshot:

If you do point to an existing SQL instance, then you need to supply a name for SQL Server Instance. Note that the SQL server must be located on the same machine; the Basic installation does not support remote SQL servers.

Also note that if the existing SQL instance Express is not a SQL 2012 Express instance, then it will be automatically upgraded to SQL 2012 Express. However, if your installation is not at least SQL 2008 SP2 Express, then you will be asked to upgrade to that level first.

The next page will run through a set of review steps, making sure that everything is configured correctly. If any errors are shown here, you need to correct them and then you can re-run the reviews. Press Next to start the configuration.

Now, the configuration wizard will perform the configuration to complete the installation of TFS 2012:

The installation is now complete. The information shown on the final screen includes the URL, which all users will use for connection, and some information about what changes were made by the configuration wizard on external resources, such as IIS and the Firewall:

You are now ready to start using TFS 2012! Check out the Quick Start section for how to quickly get started on a new project.

All you need to sign up to TFS Service is a Live ID account. If you don't have one, sign up at https://signup.live.com.

TFS 2012 can be accessed in many ways. The different roles can use different tools, as described in the introduction. If you are a developer, you can use any of the Visual Studio editions from VS 2005 and upwards, given that you have the appropriate updates for the earlier versions.

If you are a developer, you need a compatible Visual Studio version; one of these would suffice:

The editions of Visual Studio 2012, which can access TFS 2012, are Professional, Premium, and Ultimate, or for testers the Microsoft Test Manager in the Test Professional SKU. Visual Studio Express can use TFS Express edition.

If you are developing code on non-Windows machines, for example using the Eclipse IDE, then you can use Team Explorer Everywhere (TEE) to access your TFS 2012 installation. Download TEE from http://www.microsoft.com/en-us/download/details.aspx?id=29933.

Users of Office Excel and Project 2007 and 2010 can access TFS 2012 by installing the Team Explorer, which also installs the required add-in components for Office.

When installing Visual Studio 2012, it will also install the required components for Office PowerPoint that can be used for storyboarding your applications.

Users who don't use any tools can still use the TFS 2012 Web Access with its new revamped Agile Workbench solution. For license details, see http://www.microsoft.com/en-us/download/details.aspx?id=13350.

The Source Control Explorer window (available from the Home page in the Team Explorer) shows a full source control repository for the team project collection. Basically, it works in a manner similar to Windows Explorer and lets you browse, search, and perform actions on files and folders.

The workspace is a mapping between the TFS source control repository and your local development machine. You must create at least one workspace before you can download and modify anything in the source control. There are two types of workspace, namely Server workspaces and Local workspaces.

A local workspace is new to TFS 2012 and allows for local work in offline scenarios. You can check out, add, and remove files when offline. It synchronizes with the server when you're online again. The server workspace, on the contrary, keeps all the information about your workspace on the server.

Every time you check in one or more modified source files, TFS bundles these files together into a changeset. A changeset contains the modified source files, and the following information:

A changeset is atomic, meaning that it will either be fully committed to TFS or, in case of any error, not committed at all.

All the changes that are you are currently working on are automatically added to the set of pending changes. Every type of change is a pending change, including edits, moves, branches, and deletes. It is not until you check in your pending changes that these are committed to the TFS source control repository as a changeset.

The Pending Changes tab will show the files as included if they match the Team Explorer rules for files to include by default. Normally, these files are a part of the current solution. The remaining modified files in your workspace will be shown under excluded. You can move files between included and excluded by dragging them between their headings:

When you want to download the latest changes that have been checked in, you need to right-click and select Get Latest Version in the source control explorer.

Sometimes, you will need to get another specific version of a file or project. This is done by using the Get Specific Version command, located under the Advanced sub-menu in the source control.

TFS keeps a track of all changes made to the items in the source control and users who performed the change. Often, you will want to view the history of a file or a complete folder, which can be done right in the source control explorer:

You can view details of each changeset within the history list, and you can also compare the differences for a file or folder between any given versions:

When looking at the source code, you will often find yourself wondering who wrote that code and why. You can answer this question by using the Annotate function. It will show which user had last modified any particular line of code, with a link to the corresponding changeset.

When clicking on the link in the left bar, you will get the full changeset details, including comments and work items that should answer why the change was made.

Sometimes, you may work on a new feature that is partly done and suddenly get interrupted by something else. At such times, you may not want to keep your changes lying around on your local machine, but commit them back into the main repository. These changes might not even compile. This is one occasion where shelvesets are very useful. A shelveset is basically a changeset that is not checked into the main repository. You can gain several benefits by shelving your changes, a few of which are listed as follows:

When setting up the source code structure for a new project, you should always prepare for branching. To support branching, you need to make sure that the project is contained within a top-level node that indicates which branch it belongs to. The following screenshot is an example:

We have created a Main branch, where the source will be added in the beginning of the project. Later on, you can branch from the Main folder. Here we have created a Dev folder that will contain the development branches and a Release folder, which will contain the released branches. This will make sure that Main is the parent of all other branches, and any changes that are done must flow through the Main branch.

To create a new branch, select a folder in the source control explorer, right-click and select Branching and Merging | Branch.

In this example, we create a branch from the Main folder (source) and name the Target (child) branch Release\1.0.

A common scenario is that a bug may occur in production that needs to be fixed as soon as possible. We can fix the bug in the Release branch and build a new version of the product. Later, we need to merge the bug fix back to Main. Do this by selecting the Release/1.0 branch in source control, and select Branching and Merging | Merge.

In the preceding dialog box, we can select the source and the target branches (we can only select the branches that are either a child or a parent of the source branch). We can also select to merge all the changes up to a specific version (often the latest version), or select specific changesets (often called a Cherry Pick Merge).

Branch hierarchies can grow complex over time, making it hard to visualize how they are connected to each other. To view the branch hierarchy, select Branching and Merging | View Hierarchy.

In the preceding screenshot, you can see a branch hierarchy where the Main branch has three child branches—one development branch (FeatureA) and two release branches (1.0 and 2.0).

Tracking across branches

A bug is initially fixed in one of the branches. Use the Track Changeset/Work Item feature in TFS to see where the work item or changerset was initially resolved and to which branches the change have been merged.

In the following example, we have a bug (ID 27) that was initially fixed in the Release 1.0 branch:

As indicated by the colors, the bug fix was merged to Main (Changeset 60) and then it was merged to the FeatureA development branch (Changeset 61). However, it has NOT been merged to the FeatureB or the Release 2.0 branch.There is also a Timeline Tracking view that shows the same information in time sequence, which can be very useful.

Tip

Merge changes by drag-and-drop between the branches

In both these views, we can merge the changes by dragging the boxes between the branches. The drag/drop operation will open the Merge dialog box.

The Visual Studio ALM Rangers have published a branching guidance, containing industry best practices; see http://vsarbranchingguide.codeplex.com/.

There are several tools at your disposal when it comes to creating (and viewing) work items in TFS. When creating one or a few work items, you will normally use either Team Explorer or TFS Web Access.

The following screenshot shows how it looks in the Team Explorer. From the Work Items page, you can create new top-level work items from the menu:

Subsequent child work items are created inside the parent work item form. Every work item can be linked to many other artifacts in TFS, such as other work items, source control changesets, and external URLs. This is a core feature that enables full traceability in your project between requirements, design, implementation, testing, and deployment.

You create links to other items of a variety of types by using the Links tab, and pressing either New or Link to.

The most common link type is Parent/Child. This is most commonly used to break down work into smaller tasks. Since this is so common, there is a separate tab called Tasks in the Product Backlog Item work item type. This lets you create subtasks for your PBI that are automatically linked as children.

Another important tab is the Test Cases tab. This lets you create test cases (which are a work item type as well) for your requirements. You will learn more about this later in this section.

You can find work items in three ways:

A query can have several AND and OR clauses that filter the result; clauses can be grouped, and each query can be configured to return a specific set of columns and sort the order.

Here is an example of a work item query that returns all the tasks in Sprint 1 that are blocked:

This query contains five different clauses, each of which filters in a different field. Clauses can be grouped by marking them and selecting Group.

Work item queries exist in three different flavors:

Work item queries are organized per team project in a hierarchical fashion, using folders to separate groups of queries:

Current Sprint is a folder, which contains all the queries that apply to the current sprint. Note that this is only a convention, and there is no semantic relationship between the folder and the queries it contains. Also note that you can add work item queries to either My Favorites or Team Favorites, which also shows the total number of work items that those queries returned the last time they were executed.

Updating a few work items using either Team Explorer or the Web Access works fine, but often you will need to update many work items at the same time. In this scenario, you can use Microsoft Excel to batch update work items at the same time.

When using work item queries, you can right-click on them and select Open in Microsoft Excel, which will show the results of the query inside it. This works for all types of Work Item Queries; for example, flat lists, with direct links, and tree of work items.

Here is how the PBI query looks in Microsoft Excel:

When you install TFS 2012 Team Explorer (or Visual Studio 2012) on a computer that has Microsoft Excel installed, the Team ribbon is created. This is what makes the Excel TFS aware and lets you work efficiently with work items.

Since Excel cannot show a hierarchical date, it flattens the result by adding extra columns for each level.

To create a new child task for the Take Order PBI, select the row containing the Take Order work item and then press the Add Child button in the Team ribbon:

When the work item is saved, it will be given an ID (shown in the ID column). Press the Publish button to save.

The My Work hub contains all the artifacts that you are involved with during your work, across types. Work items can be activated (move to In Progress) directly in the hub, and you will also see all the code review feedback you're involved in.

The Implement UI task is available here. You can drag it directly to In Progress Work Items & Changes, to tell that you're now working on this item:

When you do this, it will automatically change the state to Active and become associated with the current pending changes.

A product backlog is central in Agile planning; this should contain everything that needs to be done for the corresponding product. Items in the product backlog are prioritized by their order on the backlog in a top to down manner.

To prioritize, you drag-and-drop the items:

To assign items to sprints, you select the item on the backlog and drag it to the sprint on the left of the screen. You will see the Iteration Path field update automatically when you do this.

To view the sprint backlog, click on the sprint link on the left side of the screen. This will show all the backlog items that are assigned to the selected sprints and their tasks:

You can add new subtasks to the backlog items by clicking on the large plus icon (+) to the very left.

To the right, you can see the current capacity information for the current sprint. It shows how much of the total work is assigned to the team in this sprint (40 hours in this case) and how much of that work is allocated to each person and to the team in total (31 hours). In this case, the sprint looks OK; we haven't over allocated the team. If we add too much work, the fields will be marked with red color.

To be able to show this information, you need to define the capacity of each team member. This is done for each sprint and is done by clicking on the capacity tab:

You set the capacity to how many hours per day each member can contribute (also restricting it to a certain activity), and to how many days during the sprint they will not be able to commit.

Development starts when the sprint is fully planned. During the course of the sprint, you normally have a daily stand-up meeting, where each team member briefly describes what they have been doing, what they will do today, and if they have any impediments. It is also a good moment to go through the remaining work for each task that is assigned to them. When doing this, you use the board task in the TFS Web Access:

The board task shows all the backlog items to the left, with the total numbers of hours of remaining work below. All the implementation tasks are shown to the right in the corresponding state column.

In the upper-right corner, a small burn-down graph is shown; you can expand it by clicking on it. This is always up-to-date. Every time you change the remaining work or add a new task, the burn-down graph will reflect it immediately.

To change the state of a task, just drag it from the left to the right. Under the hood, TFS will update the necessary fields. You can easily assign a work item to another team member by clicking on the name in the task. You can also change the remaining work by clicking on the number in the lower-left of the task:

When you drag a task from IN PROGRESS to CLOSED, Remaining Work will automatically be cleared.

To see which tasks that are allocated to a specific team member, filter the board by clicking on the All link in the upper-right corner and then select that member. You can also group the entire board by team members.

There is a corresponding Kanban board, which is also very useful to get an overview of the state of the product backlog items.

To create a build definition in TFS 2012, follow these steps:

You are done; save the build definition.

To run a build manually, right-click on the build definition in Team Explorer and select Queue New Build.

This brings up the Queue Build dialog box, where you can override several build settings and parameters for this build before starting it. The CI, Rolling, or Gated Check-in builds will start automatically when you check in. The queued build shows up under the My Builds section in the Builds hub. Double-click on it to see the build summary:

The build summary shows all the relevant information of the build, with links to the complete log and drop folders where you can access the output from the build.

You will eventually need to modify the build workflow, for example, if you want to copy the build output to a specific location. For guidance and best practices on build customization, see the Visual Studio ALM Rangers guidance for how to do that at http://vsarbuildguide.codeplex.com/.