An end-to-end view of what you can configure and customize in Visual Studio TFS

With Visual Studio Team Foundation Server (TFS), you have an integrated toolset to manage your software projects from planning through deployment. You’ll configure most of the tools using one of the client interfaces. To support specific workflow or business processes used by your organization, you might need to customize some objects. This topic provides a road map for what you can configure and what requires customization.

The following picture shows many, but not all, of the elements that you can configure or customize. All configurations can be performed for both Visual Studio Online and TFS on-premises deployments. You need to run a command-line tool or edit an XML file to make most customizations. These types of customizations can be made for TFS on-premises deployments only.

You have access to the Test Plan and Test Suite work item types (WITs) only if you’ve upgraded your application-tier to TFS 2013.3. You can now customize these objects in the same way you customize other WITs. To learn more about how to update your team project, go here.

Backlog items refer to Product Backlog Items, User Stories, or Requirements, depending on the process template used to create your team project. You can define Bugs to track code defects using Visual Studio and Test Manager.

The starting point to accessing these tools and managing your application lifecycle is to create a team project based on a process template. Process templates provide the default configuration of objects used to support all Application Lifecycle Management (ALM) features and functions. You can customize a process template before you create a team project, or you can customize objects afterwards.

The plug-ins and object files that you can customize are shown in the following picture. Plug-ins define the tasks to perform when you create a team project, most of which configure defaults, set permissions, and upload object files.

If you plan to create several team projects and want them to standardize them around the same set of objects and processes, then customize the process template before you create the team project.

TFS provides three default process templates which are compared here. To learn more, see Create a team project or Customize a process template.

Version control

You can manage source code using Team Foundation version control (TFVC) or Git. Go here for details on the differences between TFVC and Git.

Here is a view into the areas you can configure when working with source code. All of these areas are made after you have created a team project.

TFVC Set up local or server workspaces Branch and merge source code Associate a file type with a third-party compare tool Subscribe to alerts when check-ins occur Set check-in and check-out policies Restrict access/set permissions

Git Set up local or remote repositories Branch, merge, and publish code Get notified when commits are pushed Restrict access/set permissions

Default check-in policies and group permissions are defined in the process template plug-in for version control.

Plan and track work

Teams use work items, Agile planning tools, queries, and reports to plan and track work. Many elements are configurable through Team Web Access (TWA), the web client interface to Visual Studio TFS.

Work item tracking and Agile planning tools

Each team project provides several work item types (WITs) to track work. For example, the Visual Studio Scrum template provides six WITs.

WITs provide the foundation for all tracking and reporting of the software development project. You can customize the fields tracked, the workflow, and form. To learn more, see:

• Modify or add a field to support queries, reports, and workflow

• Modify or add a custom WIT

To get the most out of using the Agile planning tools, you’ll want to configure them in ways that support your team’s processes. You configure several features as shown in the following illustration.

To learn more, see Configure and customize Agile planning tools for a team project.

Some Agile planning tools and team features require Advanced access as described in Change access levels.

Teams

You can define as many teams as you need. Each team can work independently from other teams while still providing visibility on progress across the organization. You configure the following objects for each individual team.

Alerts: Define personal and team email notifications when changes occur to the team project. Home page: Configure the tiles that appear on the team home page. Schedule sprints: Define team sprints to create sprint backlog pages. Teams: Add teams to support how your organization works. Team administrators: Add administrators to manage all team-related activities. Team members: Only team members appear in the Assigned To list and capacity planning when working in an Agile planning tool. Team rooms: Support ad hoc conversations and configure events to support team activities. Work item templates: Pre-populate values for commonly used fields that support your team’s processes.

Queries, tags, filters, and reports

To list and filter work items and report progress, you can use the features listed in the following table. As indicated, you can customize queries and reports before you create a team project.

Team project portal

You can share information and support how your team works using a team project portal. Portals provide the ability to share documents, data, process guidance, and other SharePoint features. To learn more, go here.

Build

To define software builds, you can configure the following areas after you create a team project.

Build process Build definitions Build process templates Gated check-in builds (TFVC) Continuous integration builds

Build numbers Build notification email alerts Build quality values Restrict access/set permissions

Before you create a team project, you can define the default group permissions for build.

Test and lab management

If you’ve updated your team project with the Test Plan and Test Suite WITs that TFS 2013.3 provides, you can now customize these objects in the same way you customize other WITs. With these updates, as well as those provided with TFS 2012.2, you have access to the following WITs: Test Plan, Test Suite, Test Case, Shared Steps, and Shared Parameters.

Using Team Web Access or Test Manager, you can view which test cases are defined for a test suite, and which test suites are defined for a test plan. However, these objects aren’t connected to each other through link types.

To learn more about how to update your team project, go here.

Here is a view into the areas you can configure when testing your code. Go here to learn how to customize these areas in a process template.

Configure: Test configurations: Specify a combination of hardware and software that represents a user's environment to test. Test settings: Control the diagnostic data adapters that actually collect the data. Test variables: Supports specification of elements that reflect the user environment in which the software will be deployed, such as the client device type, server operating system, network speed, or database edition. Test configurations are a combination of several test variables. Test permissions: Supports configuration of security groups and permissions. Customize: Field customizations: Add a custom field, modify a pick list, or add a field rule to a WIT. Work item form customizations: Modify the form layout for a WIT. Workflow customizations: Modify the workflow definitions for the bug, test case, test plan, or test suite. Test failure types: Specifies the reasons why a test run failed. The default configuration includes: Regression, New Issue, Known Issue, and Unknown. Test resolution states: Specifies the action to take after a test run failure. The default configuration includes: Needs investigation, Test issue, Product issue, and Configuration issue.

Deploy using Release Management

Deploy your working software to your internal development, test, staging, or production servers. You configure all objects through the Release Management client.

Automate deployments with Release Management Define release paths and release templates, initiate a release Configure your release template to trigger a release from a build Add a custom release action Add a custom release tool Add users and groups, set permissions

Permissions, groups, and security

TFS defines a number of default groups and permissions within the process template that is used to create a team project. You can use default groups and their associated permissions to manage most users and meet their needs.

For more information on security and managing users and service accounts, see Manage users or groups in TFS.

Q & A

Q: How do I configure my applications to find performance problems?

A: Use Application Insights to configure your web apps to find performance problems. You’ll need a Visual Studio Online account, which you can get by going here.

Q: What is the difference between objects I can customize and the artifacts that are defined for my team project?

A: An artifact is a specific instance or definition of an object. The artifacts defined in your team project depend on the process template used to create the team project. For example, team projects based on the Scrum process template include several WIT objects, including Product Backlog Item and Bug. Go here to review the artifacts available with the default TFS process templates.

Q: Where can I go if I have more questions?

A: To find answers or post a question, visit the following forums:

• Team Foundation Server - Work Item Tracking

• Team Foundation Server - Reporting & Warehouse

• Team Web Access