Professional Team Foundation Server 2013 (2013)

What's in this chapter?

· Organizing folders within the branch structure

· Managing and storing third-party dependencies

· Managing source code and binaries for internal shared libraries

· Storing customization artifacts to manage Team Foundation Server in the version control repository

A few scenarios are common across development teams when managing source code for their applications and managing Team Foundation Server. Organizing and architecting the structure of the version control system can have a direct effect on improving the way applications are managed and built. This chapter explores some of those scenarios and discusses possible solutions to tackle each of them. When illustrating these scenarios, we will be using a Team Foundation Version Control–based team project, although you could use a Git-based team project just as easily.

Setting Up the Folder Structure for Your Branches

One common issue that development teams have centers on the organization of their source control repositories. Over time, these repositories can become unruly and downright difficult to locate. The common question around the office can sometimes be, “Where is that located in source control?”

By providing some organization to the version control repository in Team Foundation Server, you can provide your team with better discoverability of source code assets. You can also introduce best engineering practices that will make it easier to compile your applications locally and on automated build servers.

Figure 11.1 shows a sample folder structure within a branch. Notice how the folders are inside the folder indicated as a branch in Team Foundation Server version control. Essentially, the idea is to store within the same branch all of the artifacts necessary for building, testing, architecting, and so on, the product or product family. This allows you to create as many branches as the team needs to contain everything necessary for the development effort.

Figure 11.1 Sample folder structure within a branch

Later on, when you are creating a build definition that will build the entire product family, it will be useful to scope the build to the branch so that it has access to all of the artifacts that would be necessary to compile, test, and package the product family. Each of these folders and its purposes will be examined in this chapter.

Application Source Code

The primary version control folder needed for most teams is one that contains the source code for a family of products. This folder is named Source in the branch shown in Figure 11.1. Each product can be contained in a separate subfolder, and any shared libraries that are used only by the products in the product family can have subfolders under the Source folder as needed.

Additionally, teams may choose to store the source code for the automated unit tests in this folder because the unit test projects are traditionally included in the same Visual Studio solution as the product's Visual Studio projects. The development team is usually the team that manages artifacts in this version control folder, and the creation and management of unit tests is typically owned by developers.

Automated Tests Source Code

The testing or quality assurance team may end up generating source code for automated tests such as Coded UI, web performance, and load, as well as for other types of tests. They need a location in which to store the source code that implemented those automated tests, so the version control folder named Tests in the branch shown in Figure 11.1 serves that purpose.

By including the source code in the same branch as the rest of the product family, it can easily be managed across the branching structure, and it can be included to be compiled or even run in automated builds that use the branch as its source. Including the Visual Studio projects for your automated tests in the same build as your application is also a requirement for queuing automated test runs from Microsoft Test Manager to run inside of an environment.

Architecture Assets

Software architects can create valuable architecture diagrams that might also be helpful to team members implementing and testing the product family. Visual Studio 2013 Ultimate provides some powerful architecture tools, including a Visual Studio project type for modeling projects that enable the capability to store UML and other architecture diagrams in a meaningful way. The architecture assets also need a version control folder in the branch, which is shown in Figure 11.1 with the name of Architecture.

Alternatively, the architecture modeling projects and diagrams can be stored in the Source folder mentioned earlier in order to be included in the same Visual Studio solutions. The idea is to ensure that they are included in the same branch alongside the rest of the assets for the product family.

Again, by including them in the same branch, the architecture components and artifacts could be used in an automated build process. Specifically, you could perform architectural validation during compilation using the layer diagrams stored in the Visual Studio architecture modeling projects.

Database Schema

Database developers also produce artifacts to manage the schema and data in the databases used in the product family. Their artifacts can be stored in the same branch folder as well. To offer change management for the database schema, Visual Studio 2013 also includes a project type for database schema management that integrates with version control repositories. This functionality was available in Visual Studio 2012 by installing the SQL Server Data Tools add-in but is now available in all versions of Visual Studio 2013. Thus, to edit a stored procedure, you would use the same version control techniques as editing a source code file for an application.

The folder named DataSchema in Figure 11.1 is used to store database schema artifacts in the branch. The automated build process can even use the database schema “source code” contained in this version control folder to compile the schema into a deployable unit for creating a new database from the schema or update an existing database automatically to the latest schema version.

Installer Assets

If your development team needs to produce installers for the product to ship to customers, or to internal business users, or even to ease deployment of server or web applications, then a version control folder should be created inside the branch to store the installer artifacts. This particular folder is represented in the example branch in Figure 11.1 as the folder named Installer. This allows for the automated build process to have easy access within the same branch to the source code necessary to compile the merge modules and/or installers.

Build and Deployment Assets

Finally, there might be artifacts that the development team may want to store that are necessary during the build process or for deployment reasons. A version control folder dedicated to these artifacts is helpful. The version control folder for these artifacts is shown in Figure 11.1 with the name of Build.

You don't necessarily need to store the build workflow process template (.XAML) file itself in this folder. However, it is certainly an option if your team decides to store build process templates inside the branch. If you store the build process template file inside the branch, then each of those branched build process template files must be registered for use in the build system before they can be used by a build definition.

Note

Chapter 19 provides more information about managing and registering build process templates.

Third-Party Source Code and Dependencies

Traditionally, teams should not store binaries in version control. This best practice has evolved because team members would check in the bin and obj folders created after compiling a solution or project in Visual Studio. Those folders, and particularly the binaries that get created, should generally not be stored in version control even with Local Workspaces. Problems may arise when storing those folders in a server workspace because Team Foundation Server marks files coming from version control as read-only, which prevents Visual Studio or MSBuild from being able to overwrite those files.

The idea around this is that you should store in the version control branch only those source code files necessary to create the binaries and let the automated build system compile the source code into the necessary binaries. The build drop folders can then be stored on a file share that is backed up regularly and retained appropriately. Even though the Visual Studio Online (VSO) has introduced the concept of storing the build drop folders inside Team Foundation Server, it does not store them inside or check in to the branch but rather has a separate location inside the server for the outputs of compilation. This is only done in this manner because VSO doesn't have a way to talk to your drop folder within your firewall.

Note

The practice of not storing the binaries in the version control repository can also be generally applied for other types of compiled “outputs,” depending on the circumstance. For example, storing the compiled help file (that is, a .CHM file) in the version control repository would generally not be recommended because it can be compiled during an automated build process. Instead, the source files used for creating the compiled help file would be stored in version control.

However, the guideline of not storing binaries in the version control branch does not apply when it comes to managing third-party dependencies.

One folder you might have noticed in the branching structure shown in Figure 11.1 that has not been discussed yet is the Dependencies folder. This folder is exactly the version control branch location that can be used to manage the third-party dependencies. Let's take a look at two methods for managing a Dependencies folder and discuss the strengths and weaknesses of both approaches.

Folder inside the Branch

The first approach is based on the premise that everything necessary for the product family is stored inside the branch folder. This means that a Dependencies folder could be created inside the branch folder, as shown in Figure 11.1, and used to manage the third-party dependencies.

Subfolders can be created to manage the different types of third-party dependencies that might be needed by the products in the product family. For example, a UIControls subfolder can be created to store third-party custom UI controls, or an EnterpriseLibrarysubfolder can be created to store the assemblies that come from the Microsoft Enterprise Library. You might even create further subfolders to isolate the different major versions that might become available for the dependency. Separating and organizing the dependencies into subfolders will help ease the management and discoverability of the dependencies over time.

The first benefit that comes from storing the Dependencies version control folder inside the branch is that it allows the development team to manage changes to dependencies just like any other change to the products. For example, the new version of a dependency could be updated in the DEV branch for developing and testing, but the RELEASE and MAIN branches continue to use the older version until the update is merged and promoted to those branches. This approach allows for effective source configuration management of the dependencies of your application because the teams can choose when to “take” changes to the dependencies by performing the updates themselves.

Another benefit is that it allows for relative references to be used in the HintPath property for file references in Visual Studio project files. Visual Studio and MSBuild can use the HintPath property to resolve the references in a project at compile time. Using relative paths in the file reference (instead of an absolute path that may include the branch name) ensures that the reference can be properly resolved by Visual Studio, or automated build servers, no matter what the physical structure ends up being for storing branches in version control.

Listing 11.1 shows how the relative path would be used if the Visual Studio project file for ProductA used a dependency in the Dependencies folder, as shown in Figure 11.1.

Listing 11-1 HintPath property in Visual Studio project file branch dependency folder

<?xml version=”1.0” encoding=”utf-8”?>

<Project ToolsVersion=”4.0” DefaultTargets=”Build” xmlns=

“http://schemas.microsoft.com/developer/msbuild/2003”>

<!-- Section Removed for Brevity -->

<ItemGroup>

<Reference Include=”EnterpriseLibrary”>

<HintPath>..\..\Dependencies\EnterpriseLibrary.dll</HintPath>

</Reference>

<Reference Include=”System” />

<Reference Include=”System.Data” />

<Reference Include=”System.Deployment” />

<Reference Include=”System.Drawing” />

<Reference Include=”System.Windows.Forms” />

<Reference Include=”System.Xml” />

<Reference Include=”System.Core” />

<Reference Include=”System.Xml.Linq” />

<Reference Include=”System.Data.DataSetExtensions” />

</ItemGroup>

<ItemGroup>

<!-- Section Removed for Brevity -->

</Project>

A drawback to this approach is that each product family's set of branches contained in version control has a copy of dependencies that might be used by multiple product families. This can potentially cause more data storage to be used in the Team Foundation Server database. It also means that, if an update must be committed for all product families, the update must be made in each product family's branching structure independently.

However, the benefits outweigh the potential drawback in this particular case. This also ensures that teams have a better understanding of the dependencies used by the products in their product family. Teams can also actively manage the time when new dependencies are integrated into their product family's branch and actually take the update themselves on their own schedule to prevent disruption.

This approach can be considered the preferred method for managing dependencies because it falls in line with the concept of storing everything needed for an application inside the branch's root folder. It also provides for the minimal amount of drawbacks, which are negligible in the larger view of software development.

Folder at Team Project Level

Another alternative for storing dependencies inside version control is to use a common Dependencies version control folder across several product families. This folder is scoped at the team project level, as shown in Figure 11.2.

Figure 11.2 Alternative approach with a common Dependencies version control folder

The main benefits of this approach are that the storage space is not an issue, and teams have the capability to make a change to a dependency that would be picked up by all product families. Even when using this approach, the same type of subfolder organization that was described for the “folder inside branch” option can be used and is encouraged for the same beneficial reasons described for that option.

Because this common version control folder is used to centrally manage all dependencies, the work of the responsible teams can be affected, and products in the different product families can also be affected if a dependency being used causes changes that break the applications. This causes the teams to immediately fix their applications to address the breaking change in each of the branches for their product families. Teams must also address the breaking change in a branch that contains production source code (such as aRELEASE branch) before they can produce a meaningful build that works with the updated dependency. This approach does not allow the development teams to “take” changes as needed, and to fit them into their normal development cycles. Another immediate drawback that will surface is that the relative references in the Visual Studio project files may not resolve correctly, depending on the physical placement of the branches in the version control repository.

This approach can also be susceptible to breaking the file references when renaming or reorganizing version control folders in the future. For example, if a Visual Studio project file in the DEV\Source\ProductA version control folder included a file reference to the Enterprise Library assembly in the common Dependencies version control folder, the HintPath would be listed as a relative path in the project file, as shown in Listing 11.2.

Listing 11-2 HintPath property in Visual Studio project file with common folder dependency

<?xml version=”1.0” encoding=”utf-8”?>

<Project ToolsVersion=”4.0” DefaultTargets=”Build” xmlns=

“http://schemas.microsoft.com/developer/msbuild/2003”>

<!-- Section Removed for Brevity -->

<ItemGroup>

<Reference Include=”EnterpriseLibrary”>

<HintPath>..\..\..\..\Dependencies\EnterpriseLibrary\

EnterpriseLibrary.dll</HintPath>

</Reference>

<Reference Include=”System” />

<Reference Include=”System.Data” />

<Reference Include=”System.Deployment” />

<Reference Include=”System.Drawing” />

<Reference Include=”System.Windows.Forms” />

<Reference Include=”System.Xml” />

<Reference Include=”System.Core” />

<Reference Include=”System.Xml.Linq” />

<Reference Include=”System.Data.DataSetExtensions” />

</ItemGroup>

<ItemGroup>

<!-- Section Removed for Brevity -->

</Project>

However, if Features branches were created, as shown in Figure 11.3, then the HintPath property would no longer be valid because it would need an extra “..\” to represent the extra path level that the Features branches are now sitting under.

Figure 11.3 Features branches

Finally, if you use this approach, ensure that the common Dependencies version control folder is included in the workspace definition for any build definitions, in addition to the branch that contains the source code needed by the automated build, as shown in Figure 11.4.

Figure 11.4 Including the Dependencies folder in the workspace definition

Internal Shared Libraries

Companies may have multiple development teams that all work separately on the product families that each of the teams owns. At some point, those development teams may come to the realization that they want to have common types and source code to be shared among the products. There are certainly benefits to having one code base for the common library. For example, bug fixes, new functionality, and performance improvements can be introduced to multiple product families easily, and this allows for common usage patterns across the teams.

The key to a successful shared library strategy is to treat the package of common libraries as a completely separate “product family” internally. This means that it would ideally have its own release cycle (even if it is on the same cadence as another product family) and its own product backlog, and it would be owned by a specific team (whether a dedicated team or a team that also works on another product family).

The shared library product family is essentially treated as though it is a third-party dependency by the teams that want to use the shared library. It's just a third-party dependency built internally. A significant example of this is how the .NET Framework (common library) is developed alongside Visual Studio and Team Foundation Server in the Developer Division at Microsoft, both of which have dependencies on the .NET Framework.

For the following discussion, refer to the sample product families and common libraries shown in Figure 11.5. You will notice that both product families have a dependency on the shared libraries.

Figure 11.5 Product families with a dependency on shared libraries

Choosing a Location in Version Control

The first decision that must be made is the location in version control in which to store the source code for the shared libraries. Two common choices come up with Team Foundation Server:

· Dedicating a branching structure in the same team project

· Dedicating a branching structure in a different team project

Dedicating a Branching Structure in the Same Team Project

If the shared libraries are considered to be grouped together with multiple product families in one team project, you might want to contain the source code for those shared libraries in the same team project. This is especially the case if the release cycle for the shared libraries is on a similar cadence as the other product families in the same team project. The release cycle of the shared libraries must be set to “release” and stabilized before the release of the other product families. This is to ensure that any bug fixes are included, new features are implemented, and the shared libraries are tested sufficiently before any of the product family teams need to release their products.

Figure 11.6 shows an additional branching structure for the common libraries alongside the other related product families in the same team project. The team that owns the development of the shared libraries now has its own mechanism for managing change in version control.

Figure 11.6 Branching structure for the common libraries alongside the other related product families in the same team project

A different area path node structure and team can even be created to isolate the work item artifacts related to the shared libraries. This allows managers and executives to still pull reports and work item queries across the entire team project, which provides a high-level view of the progress across multiple product families and the shared libraries. Figure 11.7 shows how those area paths might be defined in the same team project.

Figure 11.7 Area paths defined in the same team project

If this approach is taken, you can also ensure that you have separate build definitions to create the binaries that the other product family teams will end up using as dependencies in their products. Figure 11.8 shows how the build definitions for common libraries might show up alongside the build definitions of other product families in the same team project.

Figure 11.8 Build definitions for common libraries

Dedicating a Branching Structure in a Different Team Project

Let's say that the development teams for multiple product families have a dependency on the common libraries, and those product families exist across multiple team projects. In this case, you can either choose one of the existing team projects or, if needed, create a new team project for managing the source code and release for the common libraries. The concept is essentially the same except that the new branching structure, build definitions, and area paths would exist in that new team project.

Storing Library Assemblies as Dependencies

Once you have defined the location for the branching structure for the common libraries, and you have created build definitions that run successfully to produce the binaries, the product family teams are ready to take a dependency on those shared libraries in their Visual Studio projects.

The process is very similar to how the team would manage this dependency as any other third-party dependency. Team members would choose when to take a new version of the dependency based on their release schedule and how they want to support their products against the new version of the shared libraries. They then find a build with high quality and navigate to its drop folder to grab the binaries and check them into the respective Dependencies folder, as described earlier in this chapter.

It is important to ensure that the product family teams choose a build coming from a build definition that includes source indexing and publishing of its symbols to a Symbol Server. This approach is used as opposed to grabbing the binaries compiled on a developer's machine from Visual Studio. This allows the developers to still debug and step through source code, even without having the Visual Studio projects in the same solution.

Enabling Debugging for Shared Libraries Using Symbol and Source Server

One common reason that developers would like to include the Visual Studio projects for the shared libraries in the same solution as their products is to make it easier to step through the source code of the shared libraries at debug time. By taking advantage of Source and Symbol Server support in Team Foundation Server Build and Visual Studio, those developers can achieve that goal, even when using a file reference for the dependency.

To support this, the development team will need to check in a binary that has been produced from a build definition configured for Source Server indexing, and then publish the symbols to Symbol Server. The development team will also need at least read-only access to the branches that contain the source code for the shared libraries—regardless of whether those folders exist in the same team project or a different team project.

This is one of many scenarios that can be solved by using Source Server and Symbol Server. Chapter 18 provides more information about enabling Source and Symbol Server support in automated builds. You can also find additional information about the Symbol Server and Source Server features available in Team Foundation Server by visiting this blog post by Ed Blankenship: http://bit.ly/SymbolServerTFS.

Branching into Product Family Branches

You may also choose to have a separate branching structure in the same or different team project, and then branch the source code folders from the shared library branch into the other product family branches. This allows developers to have copies of the shared library projects inside the same solution, and then use project references to those shared library projects.

To enable this, you must create a branch by selecting Branching and Merging Branch from the context menu of the shared library folder, as shown in Figure 11.9.

Figure 11.9 Creating a separate branching structure in the same or different team project

Once you select the Branch command, the Branch options dialog box shown in Figure 11.10 is displayed. Notice how this branch dialog box is different than the branch dialog box displayed when creating a branch from an actual branch folder. This difference exists because you are attempting to create a branch inside of an already existing branch root folder. Because the SharedLibrary1 folder is not considered a branch, it will just be created with a version control branching relationship as a folder at the target location.

Figure 11.10 Branch options dialog box

One drawback for this approach is that you will not be able to take advantage of branch or track changes visualizations. It is solely a branching relationship in version control that exists to allow for merging changes into the branching structures of multiple product families.

The team should be careful about how the shared libraries are then deployed because each would be compiling the shared library separately in the respective build definitions. The team could get in a situation where it is deploying two assemblies with the same name, version number, and so on but with different content in it.

This also demonstrates another drawback. The shared libraries can start to quickly diverge on different paths if not managed appropriately. For example, one development team may introduce a new exception-handling routine, and another team could introduce a different exception-handling routine at the same time. Later, those two teams could merge their changes back to the original parent branch for the shared library and end up with two exception-handling routines.

Managing Artifacts Using Team Foundation Server

Team Foundation Server administrators often find that they need a place to organize and store artifacts needed for managing Team Foundation Server. Interestingly, this is where the version control repository can help out those administrators. A dedicated team project can be created to store, in one convenient location, all of the artifacts that would be necessary to manage Team Foundation Server.

This team project (named, for example, TFS) can be stored in the default team project collection, and its access can be limited to the administrators of the system. For example, you can provide access for this team project only to members of the Team Foundation Server Administrators security group.

From time to time, other developers may help out with some of the custom tools that can be created to extend Team Foundation Server, or build engineers may need access to use or contribute to the master build process templates. In those situations, you can create specific team project security groups to allow privileges on an ad hoc basis without giving full access to the entire team project's repository.

The following sections explore the different types of artifacts that you might organize in this team project. Each suggestion is certainly optional and depends on your particular scenario. The premise is that you want to effectively organize the artifacts necessary to manage Team Foundation Server.

SQL Reporting Services Encryption Key Backup

In disaster-recovery scenarios, one of the commonly misplaced artifacts is a backup of the SQL Reporting Services encryption key. Without this key artifact, you could experience problems with a full restore after a disaster. Therefore, always be sure that a backup of the encryption key is stored in the TFS team project.

The thinking behind storing it in version control is that most companies will ensure that they have a backup of the key Team Foundation Server databases. The databases can be easily restored from those backups, and access to the version control repository can happen early in the disaster-recovery process. At the point when SQL Reporting Services will be restored, the administrator will have access to the encryption key backup file available in the newly restored version control repository.

Warning

To protect the contents of the encryption key, you need a password when creating the encryption key backup file. Therefore, be sure to make a note of the password in the appropriate location, according to your company's internal security guidelines.

It may be acceptable for some employees at some companies to store a text file alongside the encryption key backup file and check in that text file to the same location in the version control repository. If that option is not an acceptable practice in your organization, then ensure that the administrators will have ready access to retrieving the password during a disaster-recovery scenario.

Figure 11.11 shows the encryption key backup file available in the root of the team project's version control repository folder.

Note

Chapter 23 provides more information about disaster-recovery procedures for Team Foundation Server. Also, more information about the procedure for generating an encryption key backup file for SQL Reporting Services is available athttp://aka.ms/BackupReportingServicesKey.

Figure 11.11 Location of encryption key backup file

Process Templates

A primary reason why administrators want to manage artifacts is to be able to manage the change of process templates used in the team projects on the Team Foundation Server. Work item type definitions are the primary source of changes to the process templates in most organizations.

You should create a folder structure that is set aside especially to manage the changes to the process templates. This allows for each change to go through a check-out/check-in procedure and be audited to include the date and time the change was made, the user who made the change, and the details about the change (for example, changeset comments and associated work items). This process is very similar to how source code changes would be made to an application being built by a development team.

You can leverage each of the version control features available in Team Foundation Server. For example, you can create two branches to maintain the changes to the process templates. One branch would be for the version of the process templates used on the testingTeam Foundation Server environment, and one branch would be used to store the version of the process templates used in the production Team Foundation Server environment. This allows administrators to make changes that can be tested out first in a separate environment, and then merge those changes to the production branch when the quality of those changes has been determined.

Additionally, the TFS team project can even contain continuous integration build definitions for automatically deploying the changes to the process template's work item type definitions to the appropriate environment whenever the change is checked in to the appropriate branch. One build definition could be created for each branch to deploy to that specific environment (for example, deploy to the production environment when changes are made to the Production branch).

Note

Chapter 13 provides more information about process templates, making changes to work item type definitions, and automatic deployment of those changes using a Team Foundation Server build.

Figure 11.12 shows the branches created for managing process templates in the TFS team project's version control repository.

Figure 11.12 Branches created for managing process templates

Custom Build Assemblies

In Team Foundation Server, build servers (specifically build controllers and agents) can monitor a version control folder for custom assemblies that should be used during the build process and deploy them automatically. This feature is particularly useful for companies that have large numbers of servers in their build farm and want an effective deployment tool and change control method for the custom assemblies. It is also useful for teams who want to leverage the hosted elastic build servers feature of Visual Studio Online.

These custom assemblies can contain custom build workflow activities or even custom MSBuild tasks used by Visual Studio projects. By creating a version control folder in the TFS team project, the custom assemblies can be managed from a central location alongside other artifacts used to manage Team Foundation Server.

Interestingly, this version control folder is not used exclusively by the build servers but can also be used by end-user machines connecting to Team Foundation Server. There could be custom types or custom UI editors used by custom build process parameters that would need to be resolved whenever an end user queues a build manually. The Visual Studio clients will monitor the specified location and load the assemblies appropriately to resolve those custom types. For this reason, be sure to provide all users of Team Foundation Server read-only access to this version control folder.

Note

Chapter 19 provides more information about creating custom build activities and deploying those activities to the servers in the build farm.

Each build controller should be configured to point to this version control folder for deploying custom build assemblies. Figure 11.13 shows the Build Controller Properties dialog box and the field to set for monitoring the version control folder. The figure also demonstrates how the properties correspond to the version control folder created in the TFS team project.

Figure 11.13 Build Controller Properties dialog box

Master Build Process Templates

Another version control folder that can be created in the TFS team project's version control repository is a folder used to store all of the master build process template .XAML files. After build engineers have architected a build process template that will work for several build definitions, it is nice to have such templates stored and managed from a central location.

Build definitions in the same team project collection can be configured to use the master build process templates, even if those build definitions are defined in a different team project.

Note

Chapter 19 provides more information about architecting and customizing build process templates.

Source Code for Custom Tools

Custom tools and extensions can be created to further enhance the features available in Team Foundation Server using the Team Foundation Server Software Development Kit (SDK). The TFS team project's version control repository is the perfect location for managing the source code to use for building those custom tools.

Build definitions can be created for the suite of custom tools that compile and package those tools using the source code stored in the TFS team project's version control repository. The work item tracking artifacts in the TFS team project can even be used to manage the releases for the custom internal tools built for Team Foundation Server.

Following are examples of the types of tools that could be created and stored in this version control repository:

· Custom check-in policies

· Custom build workflow activities and build tasks

· Custom work item controls

· Web Service event handlers for Team Foundation Server events

· Custom testing data collectors (or diagnostic data adapters)

· Migration utilities and Integration Platform adapters

· Custom Code Analysis rules

· Global Code Analysis spelling dictionary

· Custom IntelliTrace event collectors

Figure 11.14 shows an example of the version control folders that can be created to store the source code for custom tools that extend Team Foundation Server and Visual Studio.

Figure 11.14 Version control folders used to store the source code for custom tools

Summary

The version control repository can quickly become unruly if left up to a team. By introducing some organization (and, specifically, some targeted methods), not only will the discoverability of the source code be improved but the method in which the application is developed is also improved. This is especially the case when third-party dependencies and internal shared libraries are needed by the application.

Additionally, storing artifacts used to manage Team Foundation Server in version control folders will allow administrators to easily access all of those artifacts in one location. You will also be able to locate key artifacts needed in disaster-recovery scenarios, as well as have a common place to manage source code for extensions to Team Foundation Server and Visual Studio.

Part II of this book has explored the features available in the version control repository in Team Foundation Server. Part III introduces the features available in the work item tracking system of Team Foundation Server. You will learn about project management, work item tracking, and reporting capabilities of Team Foundation Server. Chapter 12 introduces you to the concepts of the work item tracking system and provides the fundamentals for managing projects and work using Team Foundation Server.