Professional Team Foundation Server 2013 (2013)

What's in this chapter?

· Organizing a plan for adoption

· Setting up timelines for adoption

· Structuring team projects and team project collections

· Hardware and software requirements

Before installing or configuring Team Foundation Server, it is helpful to lay out a plan and to identify the areas that need some preparation work to ensure a successful adoption. This chapter discusses methods for gaining consensus in your organization for the adoption. You will learn about some potential adoption timelines and strategies to ensure a smooth transition for your teams from legacy systems to Team Foundation Server 2013. Finally, the discussion walks you through some of the immediate preparation steps for gathering what you will need before you start the installation and configuration of your new Team Foundation Server environment.

In Chapter 1, you read about the high-level features available in Team Foundation Server 2013, including new features for this release. Now it's time to convince your boss and team that it would be worthwhile to adopt Team Foundation Server 2013. The following sections examine some of the ways you can prepare for your proposal to your team.

Identifying and Addressing Software Engineering Pain

One key to selling the idea of an Application Lifecycle Management (ALM) solution is to identify the pain points that your organization and teams are experiencing, and to address those pain points with possible solutions. You may find that some of the common problems people are seeking solutions for are the same problems that plague your organization.

This section identifies some common problems that plague many development organizations, and it provides some helpful discussion about how Team Foundation Server and the ALM family of Visual Studio 2013 products attempt to address those pain points. You may have additional pain points that you would like to solve, and it is always good to flesh those out to ensure that you are identifying and solving them as part of your adoption of Team Foundation Server.

This book covers many of the ALM topics because Team Foundation Server is a part of the Visual Studio ALM family of products. You can find out more information about all of the different ALM tools available across the Visual Studio family in the companion bookProfessional Application Lifecycle Management with Visual Studio 2013 available at http://www.wiley.com/WileyCDA/WileyTitle/productCd-1118836588.html.

Transparency of the Release or Project

Does your team have difficulty understanding any of the following questions during the release cycle?

· Are we on track to release at the end of the month?

· How much implementation has been accomplished on the requirements in this release?

· How are our testers doing in authoring and executing their test cases?

· What changed in last night's build?

· Why did this set of files change in this recent check-in? Was it used to implement a requirement or fix a bug?

· Which requirements are getting good test coverage versus requirements that are largely untested?

· Is the company investing in the right areas of our products based on feedback from stakeholders?

· How do you balance the capacity of team members against the priority of work you want to accomplish?

· How much work is your team capable of delivering for a given iteration?

· How can you be sure the release in production matches the release that was in a test environment?

Teams that have a problem getting visibility into their release process often want to start by finding a tool that will gather all of the data necessary to easily answer some of these questions. Team Foundation Server is one of the best products available for transparency because it allows you to store all of the different artifacts from the beginning to the end of the software development life cycle. Not only does it provide a way to capture that information, but it also allows you to make informed decisions using rich links between those artifacts and systems. Team Foundation Server provides rich information by exposing the end-to-end relationships that exist across artifacts.

Collaboration across Different Teams and Roles

Some teams have difficulty providing information and communicating across different functional groups. Testers may not feel that they have enough information about bugs returned to them as rejected, and developers may feel that they don't have enough information about the requirements they are supposed to implement or the bugs they are supposed to fix. Stakeholders and business users may not feel that they have an easy way to provide feedback about the applications they interact with so that the software development teams will be able to act appropriately.

If your team is experiencing some of these problems, you may benefit from being able to easily see information and notes about the different artifacts in the software process stored in Team Foundation Server.

Automated Compilation, Testing, Packaging, and Deployment

Teams may end up spending a lot of time at the end of release cycles completing manual steps to compile, package, and deploy their applications. They may be performing these actions on a developer machine, and manually copying to staging and production environments.

These manual steps are often error-prone and can result in unforeseen issues and failed deployments. By taking advantage of the automated build system in Team Foundation Server, your team can reduce the complexity of this process and turn it into a repeatable end-to-end solution that occurs at regular intervals or is triggered by changes introduced by your developers.

Additionally, you can leverage the automated build system to introduce a “gauntlet” of checks that each check-in may go through to verify the quality of those changes by using the gated check-in feature in the Team Foundation Build system. This can help your team reduce entropy by preventing defects from ever being introduced to the version control repository.

Note

The new Release Management for Visual Studio 2013 product allows teams to define, configure, and automate deployments to multiple target environments. This tool can reduce risk and ensure repeatable deployments that support your organization's release pipeline and approval process.

See Chapter 20 for more information about Release Management for Visual Studio 2013.

Managing Test Plans

The testing or quality assurance departments may be organizing their test cases using Word or Excel documents, which can make it hard to organize your catalog of test cases. Additionally, tracking the execution progress of each test case may be extremely difficult; thus, it becomes difficult to gauge the progress of testing in your release.

Team Foundation Server allows you to manage your collection of test cases; it also allows you to manage the progress of test execution during the release cycle. This includes the ability to track tests across multiple configurations that your product or application needs to support.

Parallel Development

Development teams have notoriously experienced difficulty in managing changes across multiple lines of development that can occur concurrently. By supporting the previous release, while stabilizing the next release, and then also performing early work on a feature release, you can end up having trouble keeping each of those parallel lines of development organized. Integrating changes made between those releases is especially time-consuming and error-prone, especially if developers are manually applying fixes to each of those code lines.

Testers are often curious about how bug fixes and changes have been included in a particular release. And they might often need to figure out if fixes have been applied to other releases of the application.

The Team Foundation Version Control system in Team Foundation Server provides excellent branching and merging tools for easily managing parallel development, including the ability to track changes across branches. This helps you to easily see which branches have changes integrated into them as well as how and when those changes got there.

Note

The new Distributed Version Control system gives developers more freedom to work on multiple parallel development tasks at once. Using Git, developers can work on multiple branches within local repositories before confidently committing changes to the server.

See Chapter 7 for more information about Distributed Version Control with Git.

Adopting Team Foundation Server

The maximal value from Team Foundation Server is realized when it is used in a team. Therefore, ensuring a successful Team Foundation Server adoption requires alignment with many people in your organization. The following sections 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.

Adoption Timeline

In general, splitting up the adoption by team/application has proven to be a successful approach. Some of the effort may end up being the same for most teams, and lessons you learn from earlier transitions will help you become more successful in the following transitions. Table 2.1 presents a sample adoption timeline.

Table 2.1 Sample Adoption Timeline

Table 2.2 discusses the additional adoption steps for each team or application.

Table 2.2 Sample Adoption Timeline for Each Team

Phased Approach

Another approach that works well is adopting each piece of Team Foundation Server separately in different phases of a larger deployment project. This allows you to plan each phase, execute that adoption, and then train the teams on the new features and processes available in that particular phase.

Some find that teams are better able to absorb training for the new features when they are exposed to them incrementally. You may have a higher success rate by splitting up the adoption project, and then focusing your time and attention on making each part succeed. However, you'll eventually find some teams very eager to adopt future phases, so be sure you don't keep them waiting too long!

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

Luckily, Team Foundation Server is flexible enough that you can still get value from the product when using only one or two components of the system. Once 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 integration, you reduce the amount of unknown pain that always occurs when integrating components together to form a product. The key is to gradually remove the unknown and unpredictable elements from the software delivery process, and to always look for wasted effort that can be cut out. Using the new Release Management helps your team deploy the same build across multiple environments, no matter how complex the configuration.

Automating the builds not only means that the build and packaging process becomes less error-prone, but it also means that the feedback loop of requirement 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.

At this point, you may identify the need to document your test cases and track their execution throughout the release. With the traceability between test cases and requirements, you'll be able to better identify the requirements in your product that are covered appropriately by your testers.

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 use the reporting features to predict if you will be finished when you expect (for example, is the amount of remaining work being completed at the required rate?). You will also be able to drill into the areas that you might want to improve—for example, which parts of the code are causing the most bugs.

To put all of this together, you will more than likely end up with the following adoption phases, but you will want to adopt them in the order that works for your organization:

· Phase I: Version Control

· Phase II: Work Item Tracking

· Phase III: Automated Builds

· Phase IV: Test Case Management

· Phase V: Reporting

· Phase VI: Virtual Environments and Lab Management

You'll notice that this book has generally been laid out in this order to help you address each area in order of typical adoption.

Note

After getting used to the tooling, you should look at your overall process and adopted process templates to ensure that all of the necessary data is being captured—and that all the work item types and transitions are required. If there are unnecessary steps, 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 adjust your processes when you need to, and not only because you can. See Chapter 12 for more information about process templates, work items, and other topics related to tracking work.

Hosting Team Foundation Server

For the team to have trust in Team Foundation Server, you must ensure that it is there when they need it, and that it performs as well as possible. For organizations that depend on creating software, your version control and work item tracking repositories are critical to getting your work done. Therefore, those features should be treated on the same level as other mission-critical applications in the organization.

The Team Foundation Server infrastructure is a production environment for your company. Ideally, it should be hosted on a server or multiple servers with adequate resources (both physical memory and disk space). If hosted in a virtual environment, then you should ensure that the host machine has sufficient resources to handle the load of all guest machines, including superior disk I/O performance.

When planning upgrades, configuration changes, or when performing training, you should use a test Team Foundation Server environment. For some organizations, the test requirements justify the purchase of a hardware platform equivalent to the production environment.

However, for many scenarios, using a virtual Team Foundation environment will provide a suitable environment for testing. These virtual environments are especially useful when developing a new process template or testing work item process modifications. Microsoft provides an evaluation version of Team Foundation Server preconfigured as a virtual hard disk (VHD) file. This is frequently used as a test bed for work item modifications and new process templates.

Note

Brian Keller, Microsoft's Principal Technical Evangelist for Visual Studio ALM, publishes frequently-updated virtual machines with Team Foundation already set up and populated with working projects. These can be extremely useful for demonstration purposes and for testing new work item templates and plug-ins. You can find the full list of Visual Studio ALM virtual machines at http://aka.ms/almvms.

Identifying Affected Teams

One essential activity is to identify all of the different teams in your company that would be affected by deploying Team Foundation Server. Following are some examples of those types of affected teams:

· Developers

· Testers/Quality Assurance

· Product/Program Managers

· Project Managers

· Business Analysts

· Designers

· User Experience

· Change Management

· Release Management

· Technical Documentation/User Education

· Technical Support

· Information Technology

· Executives or other stakeholders

· Business Users

· Remote Teams

Generating Consensus

If anything, you should over-communicate any plans for rolling out Team Foundation Server and/or a new process. Change is difficult for some people, and this has been one technique that seems to ease those concerns.

Once you have identified all of the affected teams, it's helpful to generate consensus by suggesting that each team nominate a team member to represent the team as decisions are made about the deployment. This is generally a good way to ensure that everyone is involved, and that information ends up getting disseminated throughout the organization. You can have this “advisory” group help determine how to configure the server and the process that ends up being adopted. Going through this process allows those who are involved to have some buy-in to the deployment and, ultimately, champion the success of the change within their teams.

One word of caution, however, is that you should be sure to have an executive stakeholder in this group who is available to make final decisions when there are disagreements. It's important to ensure that decisions made by the group end up benefiting the business, so having this “final-authority” representative is helpful. The others in the group will feel better about giving their input and hearing why a particular decision is made, even if it's not the decision they supported.

Team Foundation Server Administrator

You will likely need to identify a resource who is responsible for managing the configuration and health of the Team Foundation Server environment. Your organization may not necessarily need a full-time resource for this task, but this will generally take a good amount of regular effort to ensure that this mission-critical environment is running smoothly for your company. This resource might fill several of the following example hats:

· Champion and lead the adoption in the organization.

· Implement process changes.

· Identify and write new reports.

· Manage permissions and administer the environment.

· Identify and implement maintenance windows.

· Design and implement branching and merging strategies.

· Architect build resources and build processes for use in the organization.

· Administer the virtual lab management assets.

Some larger organizations have even identified a team to manage each of the areas that Team Foundation Server may touch in the software development life cycle. This can be considered a shared engineering team that works with its “customers” in the organization to implement the needs of the company. Those customers are the teams using the Team Foundation Server environment internally. This team's work for managing the Team Foundation Server environment can even be prioritized by the advisory group mentioned previously, and often the team's leader serves as the chairperson of the advisory group.

A common question comes up about whether an IT or engineering organization should own the management of the Team Foundation Server environment. There are pros and cons to sole ownership by either team. IT organizations have had experience in managing corporate applications, but might not fully understand the needs of software development teams and departments. However, engineering departments might not have the expertise to manage hardware and disaster-recovery concerns that keep the servers running in optimal health.

A shared responsibility approach has proven to be successful. For example, the IT department may maintain the actual hardware; run regular backups; and take care of networking, power, and cooling needs. The engineering organization can own the application (Team Foundation Server) itself, which would include installing service packs or patches, configuring the team projects, and managing security. That shared management responsibility requires close collaboration across each department, which is essential for running a smoothly operating development environment.

Pilot Projects

A key way that your organization can learn what you might need to customize in Team Foundation Server is to identify a team, small project, or release willing to be the “guinea pig” to test Team Foundation Server. By setting up a pilot project, you can learn lots of information that might be helpful before rolling out to a larger audience in your organization.

Following is some of the information you will possibly discover:

· Custom reports you might need to provide that your business has been used to receiving from legacy applications

· Common pitfalls your pilot team has experienced that can be addressed when training other teams

· New features that might be more valuable to adopt ahead of other features in the products

Don't underestimate the amount of information you will learn from this pilot team and project. It can certainly give your organization more confidence in proving that the system will help you solve your organization's pain points.

Migration Strategies

Oftentimes, software development teams will have been using several different systems to track their source code, bugs, project management tasks, requirements, and even test cases. You might be in a situation where you want to migrate from those legacy systems to Team Foundation Server. Several different approaches and, thankfully, plenty of tools are available to assist you with your migration.

Note

If you are upgrading from a previous version of Team Foundation Server, be sure to see Chapter 27 for information on planning the upgrade instead of following the migration techniques mentioned in this section.

Version Control

Migrating from a legacy version control system to Team Foundation Server version control is one of the most common starting places for software development teams.

Visual SourceSafe

If your team is still using Visual SourceSafe (VSS), you should be aware that the product's support life cycle has ended. You should migrate to Team Foundation Server using the link to the VSS Upgrade Wizard in the Team Foundation Server Administration Console. This wizard will help you migrate source code from your VSS repositories to Team Foundation Server, keeping the change history during the migration.

Other Version Control Systems

If you aren't currently using VSS, then you have options as well. The Team Foundation Server product team at Microsoft has been working on a platform for migration and synchronization scenarios. This platform is freely available on CodePlex and is actively used internally at Microsoft. Out of the box, it contains adapters for Team Foundation Server 2008 and up, as well as Rational ClearCase, Rational ClearQuest, and file system-based version control systems.

The Team Foundation Server Integration Platform has been built on an extensible platform that allows for different adapters to be created to migrate source code from other systems. The CodePlex project has received numerous and regular contributions from the product team, and you can expect more adapters to come out in the future.

If you are feeling up to the challenge, you can also create a custom adapter for your version control system using the Team Foundation Server Integration Platform's extensibility hooks. You might consider contributing to the CodePlex project for others to take advantage of the custom adapter if they run into the same migration scenario that you faced!

Note

You can get more information about the Team Foundation Server Integration Platform by visiting the CodePlex project's site at http://aka.ms/TFSIntegrationPlatform.

There is also a family of commercially available third-party migration solutions that will allow you to migrate your source code from popular legacy and third-party source control systems.

Note

Chapter 9 discusses more about migrating from legacy version control systems, including Visual Source Safe.

Work Item Tracking

In addition to migrating source code, most teams will want to think about migrating work items from their legacy systems. These may be bugs, requirements, test cases, tasks, and so on.

Thankfully, the Team Foundation Server Integration Platform mentioned previously was also designed to move work items in addition to source code. Currently, an adapter allows you to move your legacy artifacts over from IBM Rational ClearQuest into Team Foundation Server. Again, custom adapters can be built using the extensible architecture of the Team Foundation Server Integration Platform to migrate work items from other tracking systems.

There are several other methods that you could use to import your work item tracking data. You may use Microsoft Office Excel and the integration that Team Explorer adds to allow you to import spreadsheets of information. Commercial tools are also available for importing artifacts from HP Quality Center into Team Foundation Server.

Note

Chapter 12 has more in-depth information and an introduction to Team Foundation Server work item tracking.

Structuring Team Project Collections and Team Projects

A common question that ultimately will come up after setting up Team Foundation Server is how you should go about structuring your team project collections and team projects. It's helpful to plan your strategy before installing and setting up the environment so that you make the right choices from the beginning. Changing the strategy can lead to a lot of effort in reorganizing, and you'll even find that some changes are downright impossible. Team Foundation Server supports creating a strategy that will be effective, flexible, and scalable to your organizations.

Ultimately, the strategy will be formed based on the isolation needs for your organization. Software development teams have traditionally described three constant concepts for how they managed their applications:

· Projects—These are the units of work centered on a given effort with a start and end date. You can easily map these to product releases, contracts, or initiatives. The projects and team within it usually follow a process such as Scrum, Capability Maturity Model Integration (CMMI), and so on.

· Products/codebases—These are described as the “source code” that makes up an application product, or group of products (suite/family). It is what the developers, designers, and other specialties work on, and its by-product (files such as .exe, .dll, and so on) is consumed by a customer.

· Organizations—These are the divisions, business units, departments, or teams that work on projects that deliver products to end customers.

Team project collections provide the ability to group a set of tightly related team projects. When you are thinking about them, you should focus on correlating them with products/codebases or application suites. For example, if your company makes four unique product lines that have almost no codesharing between them, it might be practical to create four team project collections. If, on the other hand, your company has several products that compose a solution or product suite with high code reuse, framework sharing, or even simultaneous release, then you will have a single team project collection.

Some organizations have multiple business units or departments that traditionally manage their own software configuration management servers/repositories. These organizations will find that team project collections also benefit them by isolating each business unit, but are still able to consolidate the management and maintenance of a single Team Foundation Server environment. This type of functionality would be described as multi-tenancy.

Ultimately, you will need to decide the isolation needs of the departments in your organization and how you might segregate certain resources, such as build and virtual lab resources based along those lines.

Note

Chapters 21 and 22 provide a more in-depth look at team project collections and scalability features.

Scope of a Team Project

At its very core, a Team Project contains all of the artifacts such as source code, work items, builds, reports, and an associated SharePoint team portal site. In general, a team project is “bigger than you think.” A good way of thinking about what must be grouped into a single team project is to think about the impact of a typical requirement for your software development project. If the requirement would affect the ASP.NET front end, Java middleware, and SQL database repository, then all these projects and teams of developers probably want to be working on the same team project.

Following are three general areas that are used when scoping a team project. But every organization is different, and yours might need to combine these aspects when deciding on your approach. For some organizations, it makes sense to have only a single team project in a single project collection. Others may have more than a hundred.

· Team project per application—In general, team project per application is the most common approach when scoping team projects, and probably the position you should first consider. Generally, requirements are addressed by the entire application, and several people are assigned to work on it. The applications typically have a long life cycle, going from inception, active development into the support, and then finally to end-of-life phases.

· Team project per release—The team project per release methodology is useful for very large teams working on long-running projects. After every major release, you create a new team project. At this point, you can carry out changes that might have come about from your post-release review. You might take the opportunity to reorganize your version control tree, improve process templates, and copy over work items from the previous release that didn't make it.

This methodology tends to be suited to large independent software vendors (ISVs) working with products with a very long lifetime. In fact, Microsoft itself uses this approach for many of its products. In these cases, it is generally safer to start as a team project per application, and then move to a team project per release (if required) to make reporting easier. This is traditionally the case if the releases tend to span a long timeframe (such as a multiyear project or release cycle).

· Team project per team—For smaller teams (fewer than 50) where the number of people working on the team tends to stay fairly static, but the applications they work on are in a constant state of flux, the team project per team approach may be most suitable. This is most often seen in consulting-style organizations, where the same group of people may be responsible for delivering applications for clients with rapid turnaround. If your team members are often working on more than one project at a time, the same team or subset of the team works together on those projects over time, or if the project life cycle is measured in months rather than years, then you may want to consider this approach.

As an alternative, a single team project collection per customer could be used for the consulting-style organizations that must provide all of the artifacts (source code, work item history, and so on) to the client at the end of the project, because the team project collection contains the entire work. If you do not have to deliver all of the artifacts of the project to the customer as a requirement, however, you should not necessarily use the individual team project collections approach.

Considering Limitations in Team Foundation Server

When deciding the appropriate team project collection and team project structure for your organization, it is helpful to understand the limitations of the feature set in Team Foundation Server that may affect your desired strategy based on your team's goals with using the product.

Ultimately, you can use the knowledge of these limitations to arrive at the most appropriate scoping of team project collections and team projects for your organization. You will want to ensure that you think about possible changes to the products, application families, teams, and organizational structure, and how these limitations may impact those changes in the future.

Renaming a Team Project

At the time of this writing, you unfortunately are not able to rename a team project once you have created it. There is no workaround for this limitation. You should ensure that you have fully reviewed and arrived at your team project structuring strategy before creating any team projects.

Additionally, you should consider the names you give to team projects that represent products or product families whose names have not been determined. Once you pick a name for the team project (especially if it uses a code name or some other early project name), that name will be used for the entire lifetime of the team project.

If you are using a larger team project, then you can use area paths to differentiate among different product families, products, and ultimately the components in those products. Area paths can be renamed and reorganized at any time. Chapter 12 provides more information about area paths.

One key difference for a team project collection is that you can change the name of a team project collection at a later time, provided you have an on-premises installation.

Moving Work Items across Team Projects or Team Project Collections

Because you can choose to use completely different process templates for team projects, you are unable to move work items across the team project boundary. Ensure that you pick the appropriate scoping level for a team project. For example, if you want to create a bug in one application, and later find out that it is really for another application in another team project, you will find out that you cannot move the bug to the other team project. In this case, you will have to create a copy (because the “bug” artifact may not even be named the same in the other team project's process template) of the work item in the next team project.

Instead, you may consider scoping the team project larger to include multiple applications in the same application family. You can then organize the applications within the team projects by using the area path hierarchy. To move a bug between two applications stored in the same team project, you would then just change the area path to the one that represents the other application. However, all applications or teams that use a team project must use the same process template. Chapter 12 provides more information about area paths.

Managing Work Items from Multiple Team Projects in Office Excel, Project, or Project Server

Similar to the previous limitation, because team projects can have different process templates, the Microsoft Office Excel and Project add-ins for managing work items do not work with work items from multiple team projects. As mentioned, you will want to ensure that you scope the team project to be larger, and use the area path hierarchy to distinguish between applications or teams. Then use the iteration path hierarchy to distinguish between releases and iterations/sprints.

Additionally, now that you are able to set up two-way synchronization with Project Server, you will notice that an enterprise project plan in Project Server can be mapped only to a single team project. If you have an enterprise project that spans multiple applications that might exist in multiple team projects, then your team project strategy will need to be modified to have a team project that contains all of those applications. However, multiple enterprise project plans in Project Server can be mapped to a single team project in Team Foundation Server. Chapter 16 provides more information about integration with Project Server and Team Foundation Server.

Managing Teams and Capacity Planning

Team Foundation Server 2012 introduced new support for managing team artifacts and membership as well as Agile planning tools, including the ability to plan sprint/iteration/project/release resource capacities. Portfolio management tools were added in Team Foundation Server 2013. These concepts are scoped within a team project. That means that a “team” has members, and the work it performs is defined inside the same team project.

The capacity planning tools plan for work only inside the same team project. Therefore, if you have team resources that are shared among multiple product releases/projects, then you will want to contain the entire set of products team members work on in the same team project if you want a single view from a team and a capacity planning standpoint. Chapter 14 discusses defining teams and using the new Agile planning tools available in Team Web Access.

Tracking Merged Changes across Branches in Multiple Team Projects

You are unable to use the branch visualization and track merged changes visualization features for branches that span across the team project boundary. In general, your branching and merging strategy should avoid creating branches across team projects if you plan to use the visualization features introduced in Team Foundation Server 2010.

You are able to have multiple branch “families” inside the same team project. You can even have different security permissions defined for each of the branch families to prevent one team from having the same permissions as other teams. You can withhold read permissions for certain teams so that they do not see all of the version control content inside the team project's version control repository. Chapter 11 discusses more options for setting up a version control repository, including the ability to have multiple product families stored in the same team project.

Reports and Dashboards Scoped to Team Project

If you have larger team projects that encompass multiple applications in an application family, team, and so on, you will notice that the standard reports and dashboards will be scoped to use the data inside the entire team project. Each of the reports enables you to filter the data, including some by area path and iteration path fields for the work item data. This does not mean that you are unable to create reports with data across team projects. This only means that the default reports are scoped to a team project.

Additionally, the SharePoint dashboard features allow you to create multiple custom dashboards. Each custom dashboard can then include web parts that are scoped to a specific area path and iteration path as well.

Moving Team Projects between Team Project Collections

Once a team project is created in one team project collection, you are unable to move the team project to another existing team project collection because there may be a conflict between the IDs used for the different artifacts (such as changeset, work item, and build unique identifiers).

One option you do have is to split a team project collection, which allows you to create a clone, and then remove all of the unwanted team projects from each copy. This allows you to essentially move a team project to a new team project collection. There is no workaround available for moving a team project to an existing team project collection.

The key takeaway from this limitation is that it is possible to split a larger team project collection into multiple team project collections but impossible to consolidate or reorganize team projects among team project collections.

Artifacts Scoped to a Team Project Collection

One of the important features of team project collections is that all of the artifacts contained within a team project collection are isolated from other team project collections. For example, all of the different link types between version control files and changesets, work items, builds, test cases, test results, and so on, can be contained only within the team project collection.

Another example is that you will not be able to add a link between a test case that exists in one team project collection and a requirement that exists in another team project collection. If you need this type of traceability, you should include team projects that need to link between artifacts within the same team project collection.

Additionally, you are unable to branch and merge across team project collections, even though you are able to branch across multiple team projects within the same team project collection. There is no workaround available for this feature, so ensure that you scope the team project collection appropriately to account for this feature limitation.

Certain hardware within a broader Team Foundation Server environment is also scoped to team project collections. For example, build controllers and agents, as well as test controllers and agents, are scoped only to a single team project collection.

Finally, you are unable to create work item queries that need to pull work items from team projects across multiple team project collections. However, you can create a work item query to pull work items from multiple team projects inside the same team project collection. Also, the reporting warehouse contains information about artifacts stored in all team project collections and team projects, so you can create custom reports that pull that information together.

Server Limitations

Team Foundation Server is an extremely scalable product. However, you should understand its limitations so that you optimize the performance of the environment. It is also helpful to know that most of the limits are not enforced by the product, and are general best practices and recommendations from the product group to maintain a certain level of performance.

Team Foundation Server can support thousands of team project collections mainly because of the support for scale-out architecture. The limits are tied more to the SQL Server hardware used in your deployment. A SQL Server instance can support 30 to 100 activeteam project collections. This range is related to the physical memory available to SQL. Active team project collections are those being accessed daily by the team.

Given this, if your deployment structure requires hundreds of team project collections, you have essentially two choices:

· You may buy additional hardware and make available more SQL Server instances for use by the Team Foundation Server environment.

· You could consider grouping team projects more aggressively within existing team project collections.

To maintain high performance, you should limit the number of team projects stored within a team project collection. The actual number of team projects to include in a team project collection is limited by the complexity of the work item types defined within the process templates being used by each of those team projects. The work item types included in the standard process templates (for example, the Microsoft Solutions Framework for Agile Software Development 2013 process template) have been shown to support more than 500 team projects on a server on adequate hardware.

There is a linear relationship between performance degradation and the number of team projects within a team project collection. Make sure you keep this in mind as you develop your team project structuring strategy and that you appropriately plan for additional hardware resources if many team projects will be required.

Preparation for a Team Foundation Server Environment

The following sections examine some of the preparation steps that are beneficial to take care of before you start to install a new Team Foundation Server.

Note

If you are upgrading from earlier versions of Team Foundation Server, you will find the upcoming sections beneficial in understanding the necessary preparation steps. You can also consult Chapter 27, which is dedicated solely to upgrading.

Understanding the Architecture and Scale-Out Options

You have multiple options when configuring your Team Foundation Server deployments. You can deploy all the components (Team Foundation Server application, SQL Server, SQL Analysis Services, SQL Reporting Services, and Windows SharePoint Services) onto one machine. This is called a single-server installation and should work fine for 500 users or fewer. In general, single-server installations are the easiest installations, as shown in Figure 2.1.

Figure 2.1 Single-server installation

For more than 500 users, a multiserver installation should be considered. There are several flavors of multiserver installations. At its most basic, there are two servers. One server is the data tier, running SQL Server and SQL Analysis Services, and the other is the application tier, running Team Foundation Server, SQL Reporting Services, and SharePoint, as shown in Figure 2.2.

Figure 2.2 Multiserver installation

Note

Notice that the SQL Reporting Services component is actually installed on the application tier server instead of the data tier server in a multiserver configuration. This is because the front-end SQL Reporting Services component is web-based and can be load balanced along with the other web-based components of Team Foundation Server. This will allow for easy and optimal scalability in the future if required by your environment.

Your organization may have an existing SharePoint Portal Server and/or a SQL Server Reporting Services Server that it wants to use in conjunction with Team Foundation Server. For that scenario, you would then have a server for running the Team Foundation Server application tier, a server for running the SQL Server databases, and separate servers for running SharePoint Portal Server and/or Reporting Services. Figure 2.3 shows a sample topology using this particular scenario.

Figure 2.3 Existing server used with Team Foundation Server

Note

Because SharePoint 2010 and later editions have higher system requirements, such as for RAM, and can be intensive on server resources, we actually recommend that you have a separate server environment for SharePoint. This is especially the case if you are taking advantage of the rich dashboard features available when using the Enterprise edition of SharePoint.

This configuration will ease the management and system resources requirement for your Team Foundation Server environment. It will also make sure that Team Foundation Server and SharePoint are not competing with one another for hardware resources on the same server.

For high-availability scenarios, clustering of machines is available at each point in the architecture. As previously discussed, the Team Foundation Server application tier machines can be located behind a network load-balancing device. The SQL Server instances referred to by the Team Foundation Server application and team project collections can also be clustered. Figure 2.4 shows an example of a larger topography that includes high-availability scaling.

Figure 2.4 Larger topography that includes high-availability scaling

Hardware Requirements

Table 2.3 shows the hardware requirements for a single-server installation, where the application tier and data tier reside on the same physical machine. However, keep in mind that these numbers are minimum recommendations, and, obviously, the more hardware you can throw at a problem, the better, especially if you use the environment more heavily. You will want to continue to monitor the environment for performance and utilization to scale the resources as necessary.

Table 2.3 Hardware Requirements for Single-Server Installation

For a multiserver installation (where you have distinct physical servers for the application tier and the data tier), Table 2.4 lists the application tier hardware requirements, and Table 2.5 lists the data tier hardware requirements.

Table 2.4 Application Tier Hardware Requirements

Table 2.5 Data Tier Hardware Requirements

Keep in mind that the application tier may be hosting SharePoint and/or SQL Server Reporting Services, in addition to Team Foundation Server. This might require you to bump up your hardware numbers in some form or fashion to account for the extra processing needed and the minimum requirements for those products.

Virtualization

Virtualization is a hot topic these days. Virtualization allows you to buy a large server and then virtually host several different servers on one physical machine. This allows an organization to make the most of a physical machine's resources. Some pieces of the Team Foundation Server environment can be safely hosted in a virtual environment, and some require careful consideration and performance tuning before being virtualized.

Ideally, the following pieces should be installed on physical servers or properly tuned virtual machines with peak performance specifications:

· SQL Server Database Engine

· SQL Server Reporting Services

· SQL Server Analysis Services

SQL Server is the foundation for holding all the information regarding Team Foundation Server. Should it become corrupted, the entire Team Foundation Server system will go down. To minimize the chances of database corruption, you should carefully consider the possible drawbacks before hosting SQL Server 2012 or higher in a virtualized environment. In some earlier editions of SQL Server, virtualization was not supported. However, this is no longer the case because there were quite a few improvements included in the latest versions.

Note

Microsoft has a great list of frequently asked questions specifically about its support policy for running Microsoft SQL Server products in a hardware virtualization environment in this knowledgebase article:http://aka.ms/SQLVirtualizationSupportPolicy. We highly recommend that you follow the advice in this support article to ensure that your organization is in the best supported position available under a virtualized configuration.

Specifically, for Team Foundation Server, you will want to monitor the disk I/O metrics to ensure that the virtualized database servers are able to keep up with the amount of I/O generated for database transactions that come from Team Foundation Server. No matter which virtualization technology you use, you will want to ensure that you set up the virtual environment for peak performance. The key is to continually monitor the performance indicators for the environment, and make appropriate modifications. Any degradation of performance should be reviewed, especially if you choose to virtualize your data tier server.

Note

For some tips on properly setting up a virtual environment that will include SQL Server, see the recommendations in Chapter 22.

The following can be safely installed in a virtualized environment with minimum to no impact on the Team Foundation Server system:

· Team Foundation Server application tier components

· SharePoint

· Team Foundation Build servers

· Team Foundation Proxy servers

· Test Controllers and Agents

· Release Management Server and Agents

Warning

Be careful when deciding to virtualize a server running Build Agents. A build will often require significant disk I/O and CPU resources, so virtualization may not be the best option. Build Controllers do not have the same requirements, so it is usually safe for them to run on virtualized environments.

Planning for Software Prerequisites

In addition to the hardware requirements for Team Foundation Server, you will want to prepare for a new installation by ensuring that certain software prerequisites are met.

Operating Systems

Like Team Foundation Server 2012, Team Foundation Server 2013 supports only 64-bit Windows Server operating systems. However, Team Foundation Server can be installed on a 32-bit client operating system (for example, Windows 8). Table 2.6 lists the supported operating systems for the application tier server.

Table 2.6 Supported Operating Systems for Application Tier

Note

Team Foundation Server supports the capability to install on a server running a client operating system such as Windows 8.1. However, client operating systems will not support reporting features, integration with SharePoint products, or the ability to run a Team Foundation Server proxy.

SQL Server

Team Foundation Server uses SQL Server to store its data, SQL Server Analysis Services to store an Online Analytical Processing (OLAP) cube for the data warehouse, and SQL Reporting Services as a presentation layer for rich reports. You can use the default instance or a named SQL instance for any of the components. Table 2.7 lists the supported versions of SQL Server.

Table 2.7 Supported SQL Server Versions

Note

You can use an existing instance of SQL Server, as long as it meets certain requirements. See the latest version of the Team Foundation Server Installation Guide available on the Microsoft Downloads site at http://aka.ms/TFS2013InstallGuide.

Included Edition

When purchasing Team Foundation Server 2013, you are able to install SQL Server 2012 Standard for limited use if you are installing on a single server. This “limited use” privilege permits you to use only that SQL instance for Team Foundation Server 2013 databases. This means that you would not be able to use the instance for any custom databases or other applications that you have installed within your organization.

You can use an additional production license of Team Foundation Server (for example, included with an MSDN Subscription) for installing the limited-use SQL Server license on a separate data tier server from the application tier server. You can read more about these licensing details in the latest version of the Visual Studio Licensing Whitepaper available at http://aka.ms/VisualStudioLicensing.

Enterprise Editions of SQL Server

If you are using an Enterprise edition of SQL Server that you have licensed separately, Team Foundation Server 2013 will take advantage of features made available only in the Enterprise edition. Following are some of the features that Team Foundation Server can take advantage of:

· Online re-indexing—This is particularly useful for the periodic maintenance jobs that Team Foundation Server runs to keep the SQL instance healthy, because it is capable of keeping the database online while it performs those steps. This can lead to better performance and reduced blocking calls.

· Perspectives in Analysis Services—The schema for the OLAP cube for the data warehouse will take advantage of a feature called perspectives. Perspectives in SQL Analysis Services allow a more focused view of the dimensions, measures, and data included in the OLAP cube.

· Index compression—Team Foundation Server will take advantage of index compression, which will help increase performance by reducing I/O and memory utilization. (This feature may require more CPU utilization, however, but shouldn't be a problem because I/O is typically the bottleneck for the data tier.)

· Clustering data tiers for high availability and redundancy—If you are looking to have a clustered data tier, then you will want to take advantage of the Enterprise edition because it allows you to have as many failover clusters as the underlying operating system supports.

· Query optimizations—Team Foundation Server can benefit from certain query optimizations available only in the Enterprise edition of SQL Server.

· Data-driven subscriptions in Reporting Services—This feature allows you to subscribe to a report and set up recurring e-mails, and so on, that use data to drive what parameters are set in each report that gets sent.

· Scale-out deployment for Reporting Services—This feature is particularly necessary if you decide to have multiple application tiers together as a Team Foundation Server farm, and want to have SQL Reporting Services installed on each of those front-end servers to be load balanced for high availability.

SharePoint Products

Team Foundation Server has the ability to integrate with a new or existing SharePoint environment. Starting with Team Foundation Server 2010, this integration is optional and not required for installation. You can choose to integrate with SharePoint at the time of installation or add it later.

Table 2.8 lists the supported version of SharePoint products that can be used for integration.

Table 2.8 Supported Versions of SharePoint Products

If you are using a full version of SharePoint Server such as SharePoint Server (SPS) 2010 or 2013, Team Foundation Server will take advantage of features available only in the full Enterprise edition (such as Excel Services). It does so by providing a set of “rich” dashboards that display charts contained in Microsoft Office Excel workbooks. The “rich” dashboards would not be available for your team portal sites when using the other versions of SharePoint products (SharePoint Foundation 2010 or 2013), but you would instead get a “lite” version of two dashboards based on SQL Server Reporting Services.

If you will be using a full version of SharePoint Server, you should consider installing the front-end components on different hardware than the hardware that will be used for running Team Foundation Server. This allows you to manage SharePoint independently of Team Foundation Server, which, in turn, allows you to lower your maintenance burden and prevent performance bottlenecks that may occur when both are running on the same server.

Note

Chapter 15 provides a more in-depth look at integrating with SharePoint.

Service Accounts

You will need several accounts. Table 2.9 lists the recommended service accounts that you will likely use when setting up your Team Foundation Server environment. The table assumes that you're using Team Foundation Server in an environment that uses Active Directory Domain Services.

Table 2.9 Recommended Service Accounts

The following is a list of best practices for Team Foundation Server service accounts:

· Built-in service accounts such as Network Service are supported, except as noted in Table 2.9.

· The service account user should be an Active Directory account if the Team Foundation Server environment consists of more than one server.

· Service accounts should be given the “Log on as a service” permission, except the Team Foundation Server Reporting service account.

File Share Folders

As you are using certain features in Team Foundation Server, you will end up needing several shared folder locations. Table 2.10 lists the recommended folder share locations and their purposes. The suggested permissions for each of these shares is for full control for the TFSSERVICE and TFSBUILD service accounts, and read-only permissions for all team members, with the exception of libraries for Visual Studio Lab Management (which should include full control permissions for the TFSLAB service account).

Table 2.10 Suggested Folder Share Locations

SMTP Server

One of the nice features in Team Foundation Server is the ability to set up custom alerts with different events that occur on the system. This allows users to self-subscribe to receiving e-mails for a multitude of different scenarios that may occur—for example, when a work item is assigned to a user, a triggered build has failed, or a check-in occurs to a particular folder in version control.

To ensure that your team members will be able to take advantage of this functionality, you must have a Simple Mail Transfer Protocol (SMTP) server that will accept e-mail traffic from the Team Foundation Server application tier server(s). Beginning with Team Foundation Server 2012, support was introduced for advanced SMTP authentication settings such as a user name and password as well as support for Windows authentication. SMTP servers no longer need to be configured only to accept anonymous e-mail delivery from Team Foundation Server servers.

Firewall Concerns and Ports Used

To ensure the best connections between the servers in the Team Foundation Server environment and also client connectivity, you will want to ensure that certain ports are opened at each firewall that network traffic may flow through. Table 2.11 lists the default ports that Team Foundation Server uses for network traffic.

Table 2.11 Required Ports

Source: Team Foundation Server 2013 Installation Guide

Friendly DNS Names

To ease future scenarios where you may want to move to new hardware, upgrade to new versions of Team Foundation Server, or scale out components, you may want to create friendly DNS entries that point to the individual components for Team Foundation Server. Additionally, it is helpful to have something “friendly” to provide to end users as a connection address instead of server names that can be cryptic.

It is particularly important for the new Web Access features and for the Source Server information permanently stored inside of debugging symbols that the endpoint used for Team Foundation Server components does not change over the lifetime of the environment, including upgrades. Friendly DNS names set your team up for the best continuity of use of each of those component services.

Note

You should set up each of the individual friendly DNS names for all of the different components listed in Table 2.12, even if they are currently all on the same server. You never know when you will want to scale out the environment to additional or different hardware. Having these friendly DNS names configured and used by the Team Foundation Server environment will allow you the most in flexibility for the change of infrastructure scenarios that will come in the future.

Table 2.12 Friendly DNS Records

Table 2.12 lists the suggested friendly DNS entries that you should create for your Team Foundation Server environment (even if it is only a single server). Each of these entries can either be DNS A or CNAME records and assume an internal DNS suffix of domain.local.

Note

For more information about how to configure all of the components of Team Foundation Server to use friendly DNS names instead of the default server names, as well as the scenarios where this is helpful, visit the blog post by Ed Blankenship athttp://aka.ms/FriendlyDNSTFS.

Legacy Visual Studio Versions

If team members are using older versions of Visual Studio, you will want to ensure they are able to connect to Team Foundation Server 2013. Microsoft provides excellent documentation describing compatibility between Team Foundation clients and Team Foundation Server 2013, including any software or patches required. You can find this documentation at http://aka.ms/TFS2013Compatibility.

The latest updates to the Visual Studio 2012 and 2013 versions of Team Explorer will work natively with Team Foundation Server 2013, but support for Git is only provided with the Visual Studio Tools for Git extension.

Earlier versions of Team Explorer can connect to Team Foundation Server 2013 after some additional installations. The Visual Studio 2010 version of Team Explorer has a Forward Compatibility Update available to allow users to connect to a Team Foundation Server 2013 environment. Existing essential functionality that was available in the IDE is maintained after installing the update. However, no new features available in the Visual Studio 2013 release are made available with the update. Those users can install Visual Studio 2013 or Team Explorer 2013 to use side by side with the older version of the IDE.

Even with the forward compatibility update installed, you will not be able to perform many of the administrative activities such as creating a team project in an older version of Visual Studio. For administration activities, be sure to use a Visual Studio version that matches the server version.

If you have team members who will be using older versions of Visual Studio (such as Visual Studio 2008, Visual Studio 2005, Visual Studio 2003, Visual Studio 6, and so on) or other development environments that support the Microsoft Source Code Control Interface (MSSCCI), then you can install the latest version of the Team Foundation Server 2013 MSSCCI Provider currently available on the Visual Studio Gallery. The MSSCCI Provider enables team members to perform essential version control operations in the legacy development environments. As with the Forward Compatibility Update, those team members should have Visual Studio 2013 or Team Explorer 2013 installed and running side by side to ensure they have access to the rest of the features of Team Foundation Server 2013.

Note

Visual Studio 2012 introduced the ability for round-tripping support of Visual Studio solutions and projects between Visual Studio 2012 and Visual Studio 2010 SP1 without requiring an “upgrade” of the solution and projects. This allowed for some team members to begin using the new functionality of Visual Studio 2012 without requiring the entire team to upgrade at the same time as long as they are at least using Visual Studio 2010 with Service Pack 1.

This support is continued in Visual Studio 2013 so other team members can work with the same solutions and projects in Visual Studio 2013, Visual Studio 2012, and even Visual Studio 2010 SP1.

Not all Visual Studio project types will support this round-tripping functionality. Many of the common project types are supported. If you have a project that does not support this, you can move it to a separate Visual Studio solution designed to be opened only in old versions of the Visual Studio IDE. More information about which project types have round-tripping support with Visual Studio 2012 or 2010 SP1 and which ones don't can be found at http://aka.ms/VS2013Compatibility.

Summary

This chapter reviewed possible ways that you can approach gaining support for adopting Team Foundation Server and examined potential timelines for adoption. You learned how to identify the key players on your teams who will be instrumental in the success of the adoption.

There are many different ways for structuring your team project collections and team projects, and this chapter discussed the different possibilities and limitations that should help you formalize the most appropriate strategy for your teams.

You learned about the different hardware recommendations and software prerequisites that will be required for certain functionality. Additionally, being prepared also means ensuring that the environment and accounts are ready before installation, so we presented a list of suggested items to check off.

In Chapter 3, you learn how to actually install and set up your new Team Foundation Server environment. You also learn how to set up the prerequisites, and identify where each component of the Team Foundation Server environment should be installed. Finally, you learn about the process of configuring Team Foundation Server and creating the first team project.