Chapter 2

Introduction to Team Foundation Server

What's In This Chapter?

• What is Team Foundation Server
• Core concepts central to Team Foundation Server
• Getting access to Team Foundation Server and connecting to it for the first time
• What's new in Team Foundation Server 2012
• Planning your Team Foundation Server adoption

Because Team Foundation Server is so fundamental to the Application Lifecycle Management offering from Microsoft, later chapters go into more depth about utilizing different aspects of the product, such as how to use it to plan your work, how to use version control when developing software, and how to make use of the build automation capabilities. In each case, the use of Team Foundation Server is explained within the context of the task you are doing—but before we can do that you need to know what Team Foundation Server is, what it provides, and how to get it.

Although a full treatment of Team Foundation Server is therefore necessary in a book about Microsoft's Application Lifecycle Management solution, this book deliberately focuses on how to use Team Foundation Server to develop software and effectively organize your teams. Team Foundation Server is highly customizable and extensible by an administrator. The book Professional Team Foundation Server 2012 (Wrox, 2011) is targeted at administrators of Team Foundation Server and individuals who wish to customize their instance heavily, though Chapter 6 of this book will give you a taste of the customizations that are possible and provide a starting point to learn more.

What Is Team Foundation Server?

Developing software is difficult, a fact that is repeatedly proven by how many projects fail. Developing software is a creative endeavor, not a manufacturing process. Consequently, an essential factor in the success of any software development team is how well the members of the team communicate with each other and with the people who wanted the software developed in the first place.

Microsoft Visual Studio Team Foundation Server 2012 provides the core collaboration functionality for your software development teams in a very tightly integrated product. The functionality provided by Team Foundation Server includes the following:

• Project management and planning
• Work item tracking (WIT)
• Version control
• Test case management
• Build automation
• Reporting
• Virtual lab management

Team Foundation Server is a server product separate from Visual Studio. Logically, Team Foundation Server is made up of the following two tiers, which can be physically deployed across one or many machines:

• Application tier—The application tier primarily consists of a set of web services with which the client machines communicate by using a highly optimized web service–based protocol.
• Data tier—The data tier is made up of a SQL Server database containing the database logic of the Team Foundation Server application, along with the data for your Team Foundation Server instance. The data stored in the database is used by Team Foundation Server's reporting functionality. All the data stored in Team Foundation Server is stored in this SQL Server database, thus making it easy to back up.

Team Foundation Server was designed with extensibility in mind. There are comprehensive APIs in .NET and Java for integrating with Team Foundation Server, and a set of events that enables outside tools to integrate with Team Foundation Server as first-class citizens. The same APIs and event system are used by Microsoft itself in the construction of Team Foundation Server, as well as the client integrations into Visual Studio, Microsoft Office, and Eclipse.

Team Foundation Server has competitors, including other enterprise Application Lifecycle Management suites and purpose-specific solutions (such as source control, a build server, or a work tracking system). As discussed in Chapter 1, the main benefit of having all these capabilities in one product is the tight integration that Microsoft has been able to achieve between the tools that you use to develop software and the tools that you use to communicate with your team and your stakeholders.

Acquiring Team Foundation Server

Team Foundation Server is a server-side product that must be acquired, installed, and configured. There are several options available for purchasing access to a server for your team. To begin with you should to decide if you want to run the Team Foundation Server inside your own firewall or if you want to explore a hosted Team Foundation Server offering.

Hosted Team Foundation Server

The easiest way to acquire Team Foundation Server is to rent it from a provider and access it over the Internet. Trial options are available, which means you can get started with no cost, and there is no need to wait for hardware to be purchased. When it comes to hosted options, there are two main routes: hosting from Microsoft or hosting from a third-party provider.

However, hosting is not suitable for everyone. Some organizations have a legal obligation to keep the data that they would store inside Team Foundation Server inside the firewall; others may require the tight user identity integration provided by Team Foundation Server's Active Directory integration. Others are just not comfortable making their source code, work items, and build accessible from any machine over the Internet. For these types of people a hosted solution probably isn't the answer.

Hosting from Microsoft

Microsoft makes available a massive cloud-hosted instance of Team Foundation Server, which, at the time of writing, was in preview form at http://tfspreview.com. Eventually this will become a full, commercial service available for customers who want to purchase Team Foundation services for their team at a low, predictable cost. At the time of writing access to the service is available for free, but Microsoft has stated that when the service becomes fully available there will be a commercially competitive charge for use of the service. However, despite the fact that the service is currently in preview mode, Microsoft still allows you to use this instance for hosting of live project data, which makes it an enticing option for people new to Team Foundation Server who want to try it out.

Tfspreview.com is hosted on Windows Azure and makes use of all the services provided by Microsoft's cloud operating system to ensure high availability, resiliency, and a full backup of your data. However, because the system is scaled to support the thousands of users who access it over the Internet—and because it is just the basic core Team Foundation services that are available, tfspreview.com comes with some limitations compared with a full on-premise installation. For example, there is no integration with SharePoint for a project portal and document library. There are also limited reporting features currently available and restrictions to the amount of customization that you can do to the server instance.

However, tfspreview.com provides all the version control, work item tracking, build automation, and project management capabilities of Team Foundation Server. Being available over the Internet makes it very easy to use when your team is distributed globally, and it is easy to get started on using the service. All you need to do is visit tfspreview.com, create an account, and your team can be up and running before you have finished reading this chapter. Access to tfspreview.com is controlled by federated Internet-based credentials; at the time of writing you need to have a Live Id from Microsoft to authenticate with the service.

As tfspreview.com is maintained by the Team Foundation Server team at Microsoft, it is always running the very latest version of the server software during their development process. Therefore new features will show up on tfspreview.com before they are made available in the standard retail installation of Team Foundation Server via an update or a new major release. For this reason you may notice some differences between some of the screens displayed in the figures of this book and the appearance of tfspreview.com at the time of reading.

Third-Party Hosted Team Foundation Server Providers

Many commercial companies can host your Team Foundation Server for you over the Internet for a small charge. They have the advantage that they have all the Team Foundation Server administrative knowledge in house and have a great deal of experience running their servers for many customers. As these companies are dealing on a different scale than that of Microsoft's hosted service, they can often be much more flexible in the capabilities they provide (at a cost). Depending on the hosting provider, you may also be able to purchase SharePoint portal capabilities, along with a full reporting instance, and get the same capabilities as if you were running Team Foundation Server in house without having to go through the up-front costs of acquiring the hardware to run Team Foundation Server or purchasing the software licenses in full before use.

The version of Team Foundation Server used by the third-party hosted providers is exactly the same as the version you would get if you installed it on premises. The only difference is that Team Foundation Server is running in their data centers or private clouds and your team accesses it over the Internet. In this book, behavior categorized as On-Premises refers to the behavior you would expect to see from your third party–hosted Team Foundation Server provider as opposed to the Hosted Service behavior provided by Microsoft's hosted offering (tfspreview.com).

As mentioned previously, in some organizations, using a third party to host such important data as your company's source code is not acceptable, and some other companies may actually be required by law to keep such data within the bounds of the corporate firewall. In those instances an on-premises option is the only one available.

On-Premises Installation

The way that the vast majority of customers enjoy the features of Team Foundation Server is by locally installing a version of the software inside the firewall. Trial versions of Team Foundation Server are available for you to download and install locally so you can get up and running quickly. You can also download a prebuilt virtual machine from Microsoft with all the software necessary to help you evaluate the product.

To purchase Team Foundation Server to run locally, you can acquire the software in retail or via a MSDN Subscription, a Volume Licensing purchase, or through a Microsoft Partnership agreement.

Also available for the first time in the 2012 release is a new version called Team Foundation Server Express. This includes the code developer features such as version control, work item tracking, build automation, all of which is available free of charge for individuals and teams of up to five users. The Express edition comes with a few limitations, namely: no support for SharePoint integration, limited to five named users, supports only SQL Express (so no reporting and a maximum database size of 10GB), and no sprint/backlog planning or feedback management.

You can upgrade from a Trial or Express edition of Team Foundation Server to a full edition at any time without losing any data. In addition you can purchase additional Client Access Licenses (CALs) if you require more than the five named users that come with the Express edition.

Team Foundation Server Core Concepts

Let's take a look at some of the core concepts that are critical to understanding Team Foundation Server. If you have been using previous versions of Team Foundation Server for a while (especially the previous Team Foundation Server 2010 release) then you might want to skip to the “What's New in Team Foundation Server 2012” section later in this chapter.

Figure 2.1 provides an overview of the Team Foundation Server components, which are explained in the following sections.

In addition to the components shown in Figure 2.1, the concepts of teams and team builds are necessary to a complete understanding of Team Foundation Server. Those concepts are also covered in the following sections.

Figure 2.1

Team Foundation Server

A Team Foundation Server instance can be physically split into many different machines. The application tier refers to the running web application that is handling all requests for data from client machines running Visual Studio. The data in a Team Foundation Server instance is stored in a data tier, which is essentially a SQL Server installation being accessed by the application tier. Although the application tier and the data tier are logically separate, you can have both installed on a single physical machine. As the application tier is the level at which you access a Team Foundation Server instance, the application tier machine name is often referred to as simply the Team Foundation Server. You refer to your Team Foundation Server by name or URL (that is, tfsserver or http://tfsserver:8080/tfs) when Team Foundation Server is installed in the default virtual directory in IIS on the default port. When talking to a Team Foundation Server hosted over the Internet, you most often use the full URL, such as https://proalm.tfspreview.com.

Team Foundation Server can scale to support a very large number of active users, depending on the hardware supporting it. Therefore, for most organizations, Team Foundation Server instances tend to be scoped according to who pays for the installation and operation of the instance, not by scaling limitations of the server.

Team Project Collection

The team project collection concept was first introduced in Team Foundation Server 2010. This is a container for team projects. Each server has one or many team project collections, and a project collection can have zero or more team projects.

The team project collection is the main level of isolation between instances on a server. In a hosted Team Foundation Server, the collection is what is provided as your account. Global security groups take effect at the project collection level. The identifiers for work items and for changesets in version control are all numbered with sequential IDs that are unique at the project collection level.

A team project collection has a one-to-one relationship with a database instance in SQL Server. Therefore, you can back up and restore at the project collection level. You can move project collections between Team Foundation Servers, and you can split the project collection to break up the distribution of team projects between the resulting collections. Using this process, you can move a team project into a new collection by cloning the existing project collection and then deleting the appropriate team projects from each of the cloned project collections.

Each Team Foundation Server instance has a default project collection, usually called DefaultCollection. As project collections were not introduced until the 2010 release, older clients that were created for Team Foundation Server 2008 will only be able to see this default collection.

Team Project

A team project is a collection of work items, code, tests, or builds that encompass all the separate tools that are used in the lifecycle of a software development project. A team project can contain any number of Visual Studio solutions or projects, or, indeed, projects from other development environments. A team project is usually a fairly long-running thing with multiple areas and iterations of work.

You need at least one team project to start working with Team Foundation Server. When the team project is created, the following are also created by default:

• Path in version control
• Default work item queries
• Default areas and iterations
• Default team

If using a Team Foundation Server instance that is also attached to a SharePoint and SQL Server Reporting Services instance, then the following are also created:

• Team project website
• Document library
• Stock reports

The granularity that you choose for your team project has important implications for how you structure your work and when you move from one team project to another.

Team projects are intended to represent the largest unit of work in your organization. For example, in Microsoft Developer Division, the whole of a Visual Studio release lives in a single team project with Team Foundation Server as an area of that project.

A team project has a single process template, and changes made to the process template of a running team project affect that team project only. The default reports and work item queries are all scoped by team project, making it easy to track and find work for that team project as an entity.

The following are also linked to the team project that they belong to and, in general, are difficult to move between team projects:

• Work Items—Each work item is attached to the team project and uses the process template assigned to it. For this reason, it is not possible to move a work item from one team project to another, although you may copy the work item between projects in the same project collection and include a link to the source work item for reference.
• Document Libraries—The team project optionally refers to a project website based on Windows SharePoint Services (WSS). The document libraries in this website are linked to this project, and all the documents, projects plans, process guidance, or other non-deliverable assets contained in the document library therefore correspond to the team project.
• Reports—All the reports created as part of one of the stock process templates are scoped to the team project level, making it easy to determine the progress of work inside that team project.
• Builds—Each build definition is tied to a team project, as are the build controllers and build agents performing the builds.
• Version Control—All items stored in version control must be stored under a team project node in the repository. All settings for version control (such as check-in policies, check-in notes, and multiple check-out support) are controlled at the team project level.
• Classifications—A team project is typically broken up into areas and iterations. An area is typically a functional area of the code that may have a subset of the whole team typically working on it. For example, a particular application may be broken into tiers: the web tier, application tier, and database tier. It is common that a feature or requirement may affect all tiers of the application, but a task or bug may just affect a small area of the code. Therefore, areas are organized hierarchically so that a feature could be assigned to the whole application in the team project, but an ASP.NET form development task may be assigned to a child area. Iterations are similarly organized. For Version 1 of the application, you may split development into several phases and, in each phase, have several short iterations (or sprints). These can be organized hierarchically in the iterations section.

Team

In Team Foundation Server 2012, teams are modeled as a core concept within Team Foundation Server. When you create a new team project, a new team is created for you by default with the name of that project. For example, if you create a team project called AdventureWorks, then a team called AdventureWorks Team is automatically created. The team initially contains just one member (who is also an Administrator), the person who created the team project, but you can easily add members to the team using their domain credentials in an on-premise install or by e-mail address for the hosted service.

As well as membership and administrators, a team has the following items associated with it:

• Description of the team, for example what they are responsible for
• Security permissions in Team Foundation Server given to members of the Team
• Areas that the team are responsible for
• Iterations that the team will be taking part in. The iterations have a start date (in the past) and end date (in the future) that control which iteration is the “current” one.
• A backlog of work associated to that team (that is, work items in that team's Area)
• A board of backlog items, showing for each product backlog item or story what associated tasks there are for that work item. Team members can easily drag and drop them into other states such as In Progress or Done.
• Alert events, for example sending an email notification when a build fails or a work item is associated to a team member
• Favorites, such as work item queries, source control paths, or build definitions that may be important to that team

For many smaller team projects the concepts of team and team project merge. But for larger team projects, you may want to create additional teams, which is why it is important to call out what belongs to the team and what belongs to the team project.

Any areas, iterations, work items, work item queries, builds, and most actual Team Foundation Server artifacts that you create are created at the team project level. By default, other teams can see them and interact with them. You can think of the team as a filter on the team project data to show which information is most relevant to that team, and therefore to you as a member of one or more teams.

Under the covers in Team Foundation Server, a team is actually just a Team Foundation Server security group with some additional properties and metadata associated with it.

Process Templates

An important fact about software development projects is that there is no single process that is suitable for delivering all types of solutions to all types of businesses with all types of teams. Therefore, Team Foundation Server was designed from the ground up to be flexible in how you want your teams to work.

The process template is a set of XML files that provide the details of how you would like your process to work. Microsoft provides the following three process templates with the default installation of Team Foundation Server:

• Microsoft Visual Studio Scrum—Previously available as an optional add-on, in Team Foundation Server 2012 the Scrum process template is not only installed by default but is the default process template used when creating new projects. It is a template designed for teams that want to base their software development on the highly popular Scrum methodology (at the time of writing the most popular of the formal Agile development methodologies). Users' needs are tracked by Product Backlog Item work items, which are broken down into Task work items. There are also work items for Bugs, Impediments, and Test Cases. The work items' states follow those recommended by the Scrum software development practice.

• Microsoft Solutions Framework (MSF) for Agile Software Development—This is a lightweight template designed for teams following a delivery process based on general Agile software development practices. User needs are tracked by User Story work items, as well as types for Bugs, Issues, Tasks, and Test Cases. In general, the work items have a simple state progression from active to resolved to closed. It is also an excellent starting point for people who want to customize a process to fit with their development organization.
• MSF for Capability Maturity Model Integration (CMMI) Process Improvement—This is a more detailed template designed for teams with more traditional process requirements—that is, those that typically have longer lifecycles and possible governance requirements that the process template would help fulfill. Note that if your organization is striving for CMMI compliance you should not consider this template as your only choice; you should still evaluate the possibilities offered by the MSF for the Agile Software Development template, among others.

In addition to the templates installed by default, many more are available to download online. If you have an existing process in your organization, it is possible to create a custom process template to match the process.

After you have created a team project with a process template, it is possible to modify all aspects of it while the project is in flight, including work item types, fields, states, and so on. This was another critical design decision taken by Microsoft in designing Team Foundation Server because Microsoft recognized that the best teams are those that continually improve and adapt their processes, and that, as the project continues, more is learned about the domain, as well as the strengths and weaknesses of the team.

Work Item Tracking

Work items in Team Foundation Server are things such as requirements, bugs, issues, and test cases. In other words, these are the items of work that your organization needs to track to manage the delivery of a software development project.

The work item tracking system is highly extensible. You can control which fields are presented to the user, which fields are rolled up into the reporting data warehouse, how the work item looks, what states the work item can be in, and how to transition from one state to the next.

All work items share certain common fields such as ID, State, and Title, as shown in Figure 2.2. They have a full history of changes recorded to every field in the work item and by whom. You can also link work items, files, web pages, or other elements in Team Foundation Server.

Figure 2.2

The work item type definitions are all configurable at the team project level. The work item types are created from the process template definition during project creation, but they can be modified as the team project is in flight. Changing the work item types for one team project in flight does not affect those in another team project, even if they were created using the same original process template.

All data about the work item is stored in the Team Foundation Server database. Any file attachments are also stored in the database.

Version Control

Team Foundation Server includes a full enterprise-class, centralized version control system that has been designed from the ground up to work well in environments that are spread across a wide geographical area over high-latency, low-bandwidth connections.

The basic model of version control in Team Foundation Server will feel very familiar if you have used Visual SourceSafe (VSS), Polytron Version Control System (PVCS), Perforce, or Subversion, but is different from Distributed Version Control Systems, such as Git or Mercurial. There have been very significant improvements in Team Foundation Server 2012 in the version control system (read more details about them in Chapter 3). There are now two modes of operation for version control; one is used with Server Workspaces, which will be familiar to users of older versions of Team Foundation Server. With a Server Workspace, all files are read-only in the local file system until you check out a file to edit it.

The new mode of operation (and the default for new installations) is Local Workspaces, which will be much more familiar to users of tools such as Subversion or CVS. With Local Workspaces, files are read-write–enabled locally, and no check-out is required before you can edit the file. This makes working offline and working outside of Visual Studio significantly easier. However, the cost of this convenience is that you have to check which files have been changed before updating those files (or “checking them in”) to the server. Also, as no server call is made before a file is updated, you receive no warning if another team member is working on a file at the same time as you until you go to perform a check-in. However, for most teams with a regular-sized code base (that is, fewer than 100,000 files) the reduction in friction in editing the files outside of Visual Studio or when offline from Team Foundation Server means that Local Workspaces are a sensible default starting point.

As is common with centralized version control systems, all check-in operations are performed against the server; you cannot check in locally.

The project collection administrator can configure which modes of operation are available and can, for example, force Server Workspaces if a more controlled environment is preferred.

In either mode, by default, Team Foundation Server allows multiple people to edit the same text-based files at the same time. This is particularly useful for .sln, .vbproj, and .csproj files in a Visual Studio project. When you go to check the file in to the server, if the latest version of that file is newer than the one you checked out, then you are prompted to merge your changes with the changes made by your colleagues.

Team Foundation Server version control contains the following features:

• Atomic check-ins—Changes you make to the files are batched up into a changeset. When you check in the files in a changeset, they are taken as a single atomic transaction. If a single file cannot be checked in (for example, because of a merge conflict) then the whole changeset is not committed. Only after the whole changeset has been successfully applied do any of the files become the latest version. This way, you can ensure the consistency of your code base.
• Associate check-ins with work items—When you perform a check-in, you may associate that changeset with one or more work items. In this way, you are able to get full traceability of requirements from the initial feature desired by the user, to the tasks required to create it, to the check-ins into version control that were required to implement the feature. This information is surfaced in the work item that you linked to, as well as being shown in the build report and also passed into the reporting system in Team Foundation Server.
• Branching and merging—Team Foundation Server supports a full path space branching model. If you desire parallel development on a code base, then you can create a branch of the code in two separate places in the version control repository, and then merge changes that have been applied to one branch into the other.

• Shelving—This includes the capability to store files on the server without committing them to the main version control repository. This is useful in a couple of different scenarios. You may want to back up changes made on your local machine to the server if you are going to be working on the files for more than a few hours or if you need to work on a different task temporarily and resume later. Another scenario is when you want to copy changes from one machine to another without checking them in (for example, a shelveset is used during a code review, to have a colleague verify your changes).

• Labeling—In Team Foundation Server, you can tag a set of files at a particular version with a textual label. This is useful for indicating which files were included in a certain build or which files are ready to move to your quality assurance (QA) process. Note that in Team Foundation Server, labels are always editable. Provided you have permission, you may add or remove files from that label at any time.
• Concurrent check-outs—Also known as the Edit-Merge-Commit model, by default, multiple people may edit a file at the same time. If a file were modified while you were working on it, then you would be prompted to merge the changes with the latest version of the file.
• Follow history—If you rename or branch a file then you are able to view the history of that file before it was renamed or branched. You can also follow the history of a file from before it was branched or merged.
• Check-in policies—When performing a check-in, Team Foundation Server provides the capability for the client to run code to validate that the check-in should be allowed. This includes performing actions such as checking that the change is associated with a work item, checking that the code passes static code analysis rules, and so on. Check-in policies are also an extension point in Team Foundation Server so that you can create your own, should you wish to do so.
• Check-in notes—In some organizations, it is necessary to capture metadata about a check-in (such as the code reviewer, or a reference to a third-party system). In other version control systems, this is frequently accomplished by requiring that the check-in comment follow certain unenforced conventions. Team Foundation Server provides check-in note functionality to capture this metadata. A team project administrator may add or remove check-in notes at the team project level, as well as make a particular check-in note mandatory.
• Team Foundation Server proxy—Frequently, organizations have regional development centers separated from the main development offices or the data center hosting the Team Foundation Server environment. When a “Get” is performed from version control, files are downloaded to the client machine. In the remote office environment, this often means that the same files are downloaded over the wide-area network (WAN) to every client machine involved in the development. Team Foundation Server provides an optional proxy server that may be installed in these remote offices. In those scenarios, the clients may be configured to perform the download via the proxy so that the proxy may cache the downloaded files at the remote location. In that way, the majority of the developers in the remote office will be downloading files from the proxy server local to them, thus removing traffic from the WAN and improving performance.

Team Build

Team Foundation Server provides a fully featured build automation server to enable you to standardize the build infrastructure for your team. Team builds are set up in the system as a build definition. You provide the build definition with information as to what you want build—that is, the folders or files in Team Foundation Server version control that contain the sources to be built, and the projects or solutions in those folders to build. You also specify when to perform the build using a trigger, such as building on every single check-in (Continuous Integration), building on a schedule, or validating that your changes pass the build process before check-in (known as a Gated Check-in).

Accessing Team Foundation Server

There are many ways for a team member to interact with the core services in Team Foundation Server, including the following:

• Web browser
• Visual Studio
• Eclipse-based development environments
• Microsoft Test Manager
• Team Foundation Server Administration Console
• Microsoft Excel
• Microsoft Project
• Command-line tools
• Third-party integrations

The following sections examine each of these, including the functionality they provide and basic usage.

Accessing Team Foundation Server from Visual Studio

Team Foundation Server functionality is installed as a standard part of the install of a Visual Studio edition (including the Express editions).

Assuming that you have an account, connect to your Team Foundation Server by clicking on the Connect to Team Foundation Server link on the Visual Studio Start Page or in Team Explorer (View, Team Explorer).

If your desired server is not available in the Servers drop-down, click the Servers button and then click the Add button to connect to your Team Foundation Server. As shown in Figure 2.3, you can enter the server name or provide the full URL given to you by your Team Foundation Server administrator.

Figure 2.3

After you have added the server, select the project collection that contains your team projects and select the team project or projects that you want to work on.

Your selected team project displays in the Team Explorer window. The Team Explorer window will come as the first big surprise for users used to an older version of Visual Studio. In Visual Studio 2012 the Team Explorer experience has been completely revised to remove clutter and have a more focused experience. The home page that displays when you first connect to a team project is shown in Figure 2.4.

Figure 2.4

The sections that appear in the page depend on the version of Visual Studio that you have installed and the capabilities installed in your Team Foundation Server. For example, the My Work section is only displayed in Premium and Ultimate versions of Visual Studio. The Documents section displays when the team project is connected to a SharePoint portal, and the Reports section displays when the project has an associated reporting service site. However, all versions of Team Explorer display the Pending Changes section along with Work Items, Builds, and Settings. Clicking each section takes you to that page, which contains other sections. For example, clicking on Work Items takes you to a page that contains your favorite work item queries and a tree of the available work item queries on the server (see Figure 2.5).

Figure 2.5

To change pages or projects or to connect to a different project, click the page header and a drop-down menu displays that enables you to change pages or connect to a different team or project (see Figure 2.6).

Figure 2.6

Accessing Team Foundation Server through a Web Browser

Another area that has undergone major changes in Team Foundation Server 2012 is the web-based view of the server (often called Web Access). You can view your server by navigating to its URL in a browser or by clicking the Web Access link in the Team Explorer. For example, if your server internally is called tfs2012, then by default you would navigate to http://tfs2012:8080/tfs. If your machine is accessed over the Internet, then a URL such as proalm.tfspreview.com is probably used.

Web Access (Figure 2.7) is ideal for users who do not want to install a dedicated Team Foundation Server client on their machines. At a high level, “when fully licensed,” it offers the following functionality from the browser:

• Backlog and iteration planning
• Task board
• Create and edit work items and work item queries
• Manage areas and iterations
• Administer permissions and team membership
• Read-only access to version control
• Queue and manage build definitions

Figure 2.7

Using Team Foundation Server in Microsoft Excel

As part of the Visual Studio Team Explorer installation, integration into Microsoft Excel is provided by default and a Team tab is available on the ribbon in Excel. This allows the capability to add and edit work items directly from Excel spreadsheets, as shown in Figure 2.8, as well as the creation of Excel-based reports using data directly from Team Foundation Server.

Figure 2.8

Using Team Foundation Server in Microsoft Project

Integration into Microsoft Project is also provided as part of the Team Explorer installation. This provides the capability to add and edit work items directly from Microsoft Project and to view data about the progress of these work items.

Command-Line Tools for Team Foundation Server

Team Foundation Server includes a set of command-line tools as part of the Team Explorer installation. The main command-line tool to be aware of as a user is tf, which is available from a Visual Studio 2012 command prompt. You can also install it separately on non-Windows–based systems such as Mac OS X, Linux, and many other Unix flavors.

The tf command provides full access to Team Foundation Server version control functionality, including features in Team Foundation Server version control that are not exposed via the graphical clients.

Accessing Team Foundation Server from Eclipse

For members of the team who are using Eclipse-based IDEs (including IBM Rational Application Developer or one of the many other Eclipse-based environments), full access to the Team Foundation Server capabilities are available from Microsoft using the TFS Plug-in for Eclipse as part of Team Explorer Everywhere.

As you can see in Figure 2.9, at a high level, the Eclipse integration provides all the same functionality that a developer inside Visual Studio would utilize, including the following:

• Full version control integration (check-out, check-in, history, branch, merge, label, synchronize, and so on)
• Full work item tracking (create, edit work items, and work item queries)
• Full team build integration (create, edit, and manage builds and build definitions)
• Access to team reports and documents

Figure 2.9

Windows Explorer Integration with Team Foundation Server

As part of the Team Foundation Server power tools available at http://aka.ms/tfpt, a Windows Explorer shell extension is available as an optional installation. This provides access to the basic version control functionality of Team Foundation Server from a standard Windows Explorer window and is most useful when working with Team Foundation Server version control outside of Visual Studio or Eclipse.

Access to Team Foundation Server via Other Third-Party Integrations

Team Foundation Server supports a rich and vibrant third-party ecosystem. As discussed previously, the same .NET and Java object models used by Microsoft to talk to Team Foundation Server are also available for developers in third-party companies to integrate with. Integrations are available into other parts of the Microsoft Office suite (such as Word and Outlook). In addition, many development tools now integrate with Team Foundation Server using the extensibility hooks provided by Microsoft.

For older development tools that support the Microsoft Source Code Control Interface (MSSCCI, pronounced “miss-key”) plug-in model for version control, Microsoft has a MSSCCI provider for Team Foundation Server as part of the power tools.

What's New in Team Foundation Server 2012

There have been three major changes in Team Foundation Server 2012: improving developer productivity, enhancing support for Agile planning best practices, and moving to the cloud with the Team Foundation Service. Team Foundation Server 2010 brought in significant architectural changes to Team Foundation Server. Team Foundation Server 2012 keeps the same core architectural building blocks as the 2010 release, but a whole new set of features has been built on top of it. Although many of these features are explained throughout this book, if you have used a previous version of Team Foundation Server then the features described in the following sections will be new to you.

Version Control

Team Foundation Server 2012 has brought in the biggest fundamental change to Team Foundation Version Control since the original release in 2005 with a feature called Local Workspaces, which is explained in detail in Chapter 3. In previous versions of Team Foundation Server, all state information about the files from version control that you had on your machine was stored in a Workspace on the server (or what is called a Server Workspace in Team Foundation Server 2012). Similar to Microsoft's earlier version control system, Visual SourceSafe, files were read-only locally until you explicitly checked out the file from version control, letting the server (and potentially everyone else connected to your team project) know that you were working on it. When getting files from version control, the server was already aware of the state of your local machine through the Server Workspace, and so it could quickly send you only the files that had changed since your last Get. When checking files in to version control, only the files you had checked out needed to be sent to the server. This had great advantages in terms of scalability (as the server thought it knew everything about your file system and so had to send you only the items that had changed) and in terms of collaboration (as the server could warn other team members when someone was working on the same file as they were). However, this meant frequent calls to the server every time you wanted to work on a file, which made it harder to work when you needed to be offline from the server.

In Team Foundation Server 2012, a Local Workspace stores all this workspace state locally, meaning fewer calls to the server during editing of files and a better offline experience. There's also another important advantage. Files in a local workspace are read/write when a Get is first performed against the server. This makes it a great deal easier to work with files in Team Foundation Version Control when working outside of the IDE integration built into Visual Studio or Eclipse. There is no longer an explicit check-out operation involving communication with the server, and, even better, the last version downloaded from the server is kept locally, which means it is very easy to compare your local changes with the version you had downloaded from the server without requiring any server calls.

These benefits come at the cost of features that Server Workspaces have—namely that when a check-in is performed, a scan of the files in the local workspace has to be conducted to see which have changed since they were downloaded from the server. When a Get is performed, the server has to query the client to ask which versions of all the files it has, so that it can send you the files that have changed since the last time you did a Get. Finally, because you are not telling the server when you are editing a file, other team members are not made aware of this, and so it is easier to find two team members working on the same file at the same time.

Despite these disadvantages, it was found that the improved offline functionality and the reduced friction in editing files outside of Visual Studio makes Local Workspaces a more attractive proposition for the majority of development teams, and Local Workspaces are now the default in Visual Studio 2012. However, for teams that have very large code bases or that prefer the increased communication to tell who is working on which files, the option exists to set the default workspace type to the traditional Server Workspace.

The changes to version control in 2012 go way beyond Local and Server Workspaces. A user's full name (the Display Name in Active Directory) is now used in all views instead of the logon ID, which in some organizations could be very obscure. Functionality has been added to the server to allow the transparent handling of the execute bit found on many non-Windows file systems. Merge capabilities have been enhanced, with more changes automerged than in previous versions. In general, lots of small usability improvements have been made to make working with Team Foundation Server Version Control a lot easier for the average developer.

Web Access

The most visible change to Team Foundation Server 2012 is the completely rewritten web interface. Not only does the web interface use the Metro design language common in many new Microsoft products, but it is much more responsive and scales to support many more concurrent users than before. The interface has also been rebuilt from the ground up to take advantage of modern browser technologies; therefore, it does a lot of the work of saving data to the server in an asynchronous fashion, which further improves the user experience. With the addition of supporting things like keyboard navigation and limited support for touch-based technologies, the web interface is now a more-than-credible, full-featured client for people who want to work with Team Foundation Server but who do not want the overhead of installing client software. In fact, in the areas of managing security or alerts or performing project planning, the web interface is the only interface. The only time a user would absolutely need to install the client software is when he wants to use version control or wants integration with other applications on the client machine (such as Excel or Microsoft Project).

Several new features have been added into the completely revised web interface: product backlog management, sprint planning, and task board experience (detailed in Chapter 11). All security and permissions management is done through the web interface. In addition, a powerful new alerts subscription experience has been added via the web interface.

Team Explorer

The old tree-based Team Explorer originally seen in Team Foundation Server 2005 has been replaced in Team Foundation Server 2012 with a new version based on a hierarchy of pages. The idea is to be task-focused in Visual Studio and Eclipse, be more user friendly, and give more pertinent data to the user while requiring less screen real estate to do so. The new Team Explorer is still the on-ramp into the majority of Team Foundation Server functionalities in the clients, but it is now also team-focused.

Teams

As mentioned earlier in the chapter, Team Foundation Server 2012 finally promotes the notion of a team as a first-class concept. When you create a team project, a default team is created and you pick which team you are working on in Team Explorer. Visual Studio takes data about your team to help set default areas and iterations in the work item–tracking experience. In Web Access, the entire experience is team-aware, showing you data about your team's current iteration.

Work Item Tracking

The improvements to the work item–tracking experience do not stop at the web interface. Visual Studio's work item–tracking experience has been enhanced with a new, more simplified look and feel, as well as several more low-level features.

The Cloud

By making available a hosted Team Foundation Service in the cloud at http://tfspreview.com, Microsoft has removed the barrier of entry for teams that want to use the Application Lifecycle Management features of Visual Studio but do not want to run their own Team Foundation Server. The effect of making Team Foundation Server available over the Internet has also brought about changes to many aspects of the system—for example, you are now able to authenticate with this hosted Team Foundation Service using a browser-based federated authentication mechanism rather than being forced to use a Windows-based login. The Team Foundation Build service now uses a polling-based model to detect when a new build is requested rather than the old push model, which makes using a build server in a different domain or outside the firewall much easier for on-premise installations of Team Foundation Server as well.

Adopting Team Foundation Server

The value of Team Foundation Server is realized when it is utilized in a team. Therefore, ensuring a successful Team Foundation Server adoption requires cooperation from many people in your organization. This section should help you avoid some common pitfalls and provide you with some suggestions on where to start with what may seem like a large and daunting product.

When introducing any new tooling into a large organization, it is important that you address the key pain points first. For many companies, traceability of work through the development lifecycle is often an area that is being poorly addressed by existing tooling. For others, the version control system being used may be out of date and performing poorly. It is, therefore, usually the work item–tracking or version control components that people first start using when adopting Team Foundation Server.

Luckily, Team Foundation Server is flexible enough that you can still get value from the product when only using one or two components of the system. When you have adopted both version control and work item tracking, the next area to tackle to gain the most benefit is likely to be Team Foundation Build. By automating your build system and increasing the frequency of integrations, you reduce the amount of pain that always occurs when integrating components to form a product.

The key is to gradually remove the unknown and unpredictable elements from the software delivery process, all the time looking for wasted effort that can be cut out.

Automating the builds not only means that the build and packaging process becomes less error prone, it also means that the feedback loop of requirements traceability is completed. You are now able to track work from the time that it is captured, all the way through to a change to the source code of the product, and into the build that contains those changes.

After a period of time, you will have built up a repository of historical data in your Team Foundation Server data warehouse, and you can start to make use of the reporting features to predict if you will be finished when you expect (that is, if the amount of estimated work remaining on the system is reducing at the required rate). You will also be able to drill into areas that you might want to improve—for example, which parts of the code are causing the most bugs.

It is after a period of getting used to the tooling that you want to look at your process templates and ensure that all the necessary data is being captured—but, equally, that all the work item types and transitions are required. If there are unnecessary steps, then consider removing them. If you notice problems because of a particular issue, consider modifying the process to add a safety net.

It is important to adjust the process not only to fit the team and organization, but also to ensure that you only adjust your processes when you need to, and not just because you can.

Check-in policies represent a key area where Team Foundation Server administrators have a temptation to go overboard at first. Check-in policies prevent checking in of code that doesn't meet the requirements programmatically defined in the check-in policy. However, each policy has a performance penalty for the whole team, not only in running the policy on each check-in, but also in ensuring that the policy will pass before checking in the code.

A problem with developers who are not checking in code in small iterative changes cannot be easily remedied by introducing a check-in policy—the policy alone will provide some discouragement for checking in. Therefore, check-in policies should be introduced over time and when the need is identified by the whole team.

Summary

This chapter introduced Team Foundation Server and discussed its role in bringing the team together when developing an application. You learned about some of the core concepts at the heart of Team Foundation Server, different ways to access the data in your organization's server, and what is new in the 2012 release of the product. Finally, you learned about some points that you should bear in mind when planning your Team Foundation Server deployment.

Chapter 3 looks in detail at using the version control features of Team Foundation Server and discusses the important new changes brought about in this latest release.