Puneet Ghanshani

Chief Architect at Microsoft

11 minute read

This article will briefly describe the high-level architecture of Team Foundation Server.  It will help you understand the different tiers in TFS, their responsibilities and firewalls.

Heard of TFS as a Service, what is it?

TFS as a Service is a cloud-based application life management (ALM) system that integrates source control management, product backlog, build automation, quality and deployment and encourages team collaboration to achieve efficiency in following processes.  In its free service offering, you can register on http://tfs.visualstudio.com for an account and get started.  All the infrastructure (all tiers) is pre-configured on an elastic-cloud owned by Microsoft.  As a consumer, you would be provided with services without having to go through the configuration part of TFS.

But we are not allowed to upload our code to public clouds in my organization?

If you are working in an enterprise with restricted environment, chances are that you have your infrastructure on which TFS has been installed.  This is to have enhanced security and sometimes to comply to the laws of the nation where the data resides.

Now in this case, you will have to configure the Team Foundation Server on your own and hopefully this article will serve as a good start.

Architecture

TFS is primarily structured into 3 layers. 

  • Data Tier – TFS uses SQL Server as its data storage
  • Application Tier – The application tier consists of
    • TFS Server – Typically a Windows Server 2008/2012
    • Team Foundation Web Services  -  These web services (http/https) act as a facade for TFS clients.  They exchange data with their clients using Client Object Model.
    • Server Object Model – Data exchange between TFS Server and the SQL Server (may be on a different VM/physical box) happens using Server Object Model.
  • Build Tier – The build tier consists of
    • Build Service – The build service (ASP.NET Worker Process) contains of Build Controllers and Build Agents
    • Build Process Object Model – The process object model contains of the process workflow that has to be followed when defining the build definition
    • Client Object Model – Client Object Model is the data exchange between TFS Server (Application Tier) and Build Service

It is important to understand that the application tier referred above is the application tier of TFS and not your business application.  Based on several factors such as geographical spread, server-load, network topology, proxies, etc. you may have one or multiple servers in application tier.  You can configure the build tier on the server forming the application tier.  Some deployment scenarios prefer configuring one build server for multiple TFS servers.

Desktop

A TFS Server can hold more than one code-repository and have isolated & customized build process(es) set up on one or multiple build servers.

Let’s understand this with an example -

Your TFS server url is https://YourTFS.visualstudio.com. This TFS Server can host multiple TFS Projects say ProjectA, ProjectB and ProjectC.  Each project has a code repository say RepositoryA, RepositoryB, RepositoryC and each repository has 4 branches – Development, SIT, UAT, PROD.  The code in the repositories resides on the Data Tier and is accessible using client applications that interface through the Application Tier.

Now, for each branch you can configure one or multiple build processes.  For PROD, you may like to have Nightly Builds, for Development you want to have a build triggered at every check-in and so on…  These builds require a build server.  You can use 1 build server for all the builds or you can have a separate build server for each Repository, or you can share build server between 2 repositories.

The decision to use one-build server or more depends on the peak-load, expected build queue, h/w infrastructure and a lot of other parameters.  If you do not want build services, you do not need to configure a build server at all.

With this understanding, we will deep dive into the responsibilities of each tier

Data Tier

Data Tier is formed of a SQL Server running on a Windows Server VM/physical machine.

A SQL Server consists of following databases

  • TFS_Configuration  - Configuration Database that stores the TFS resources and settings
  • TFS_Warehouse  - Data warehouse database for report generation
  • TFS_Analysis – Aggregated data of all Projects on a TFS server
  • Project databases – Database for each Project in the collection

In TFS 2013, you may see some additional databases (with names starting with WSS) that are required to manage the TFS Administration Portal.  This administration portal runs on SharePoint Foundation.

Application Tier

The application tier consists of components such as

  • Version Control – Source code versioning & management
  • Build Service – Light-weight ASP.NET Worker Process that interacts with the Build Tier
  • Work Item Tracking – Product backlog, bug, work-item tracking & management
  • Team Foundation Framework Services – Web services, Registry, Security, Event, Identity Management, Administration
  • Administration Portal – Built on SharePoint Foundation, the portal serves as one-stop for defining projects, team, work-items, reports, permissions, etc.

All these components are hosted on IIS and Windows Services on a Windows Server VM/machine.  The Team Foundation Framework Services act as a facade for all client tools like TFS Explorer, Visual Studio, etc.

Build Tier

Build tier consists of build services that enable configuring a build controller and build agents.  A build controller controls the build queue and assigns the responsibility of build to a most available build agent.  If no build agent is free, it will queue the build request.

It is not necessary to have the controller and agent on the same machine.  This allows creating a build farm that can have multiple build machines.  One of the scenarios for an enterprise build environment would be

A build farm with S servers on which C (C<S) controllers are running and A (A>S>C) build agents are running. In such a scenario, the likely hood of a build getting queued for a long duration is rare.  However, actual values of A, S, C depend on number of applications, peak-load, build time, locale, infrastructure costs, cross-border restrictions, etc.

Firewalls

TFS architecture has been designed to allow extensibility and building a large farm at data-tier, application-tier or build-tier.  When configuring TFS on a farm, the inter-server communication happens through web services.  In an enterprise environment with high-security, you may have to check if any of the ports used in web service communication is blocked.

By default TFS uses following ports

  • Team Foundation Administration Portal and Reporting – port 80, 443
  • Team Foundation Client Web Services – port 8080
  • MS-SQL – port 1433 (TCP)
  • Team Foundation Application Tier Web Services – port 8080
  • Team Foundation Data Tier Web Services – port 8080
  • Build Services – net.pipe, 9191, 443

 

Hope this helps in understanding TFS architecture.

You May Also Enjoy