Team Foundation Version Control (Azure DevOps)
Project hosted on Azure DevOps can use either of the following version control systems:
Git — an open-source distributed version control system originally authored by Linus Torvalds. To connect TeamCity to Git repositories on Azure DevOps, set up Azure DevOps OAuth connections. See this article for more information about features common to all VCS roots that target Git repositories: Git.
Team Foundation Version Control (TFVC) — a version control system exclusive to Azure DevOps, formerly known as Team Foundation Server (TFS) and Visual Studio Team System. TeamCity communications with TFVC repositories are carried out by Azure DevOps PAT connections.
This article focuses on TFVC repositories only.
Cross-Platform Azure DevOps Integration
The TeamCity integration with Azure DevOps can work on Windows, Linux, and macOS. TeamCity servers and build agents can interact with Team Foundation Servers 2012 or later and with Azure DevOps Services out of the box.
There are two operating modes available for this type of VCS root: default and cross-platform. If Team Explorer is present on the Azure server, TeamCity uses the default mode. Otherwise, it switches to the cross-platform mode.
When detecting the Team Explorer version, TeamCity checks .NET GAC and the following paths:
Windows x86: %CommonProgramFiles%\Microsoft Shared\Azure DevOps Server\%version_number%
Windows x64: %\CommonProgramFiles(x86)%\Microsoft Shared\Azure DevOps Server\%version_number%
The Server URL in the following format:
Specify the root directory using the following format:
Specify a user to access Azure DevOps Server. This can be a username or
Leave this field empty to let Azure DevOps select a user account that is used to run the TeamCity Server (or Agent, for the agent-side checkout).
Enter the user's password.
The agent-side checkout is supported on Windows, Linux, and macOS agent machines.
TeamCity automatically creates an Azure DevOps workspace for each checkout directory. The workspace is created on behalf of the user whose account is specified in the VCS root settings.
By default, the created Azure DevOps workspace uses the location defined in the TFS server settings. You can force TeamCity to use a specific workspace location via the build configuration parameter
teamcity.tfs.workspace.location set to
The created Azure DevOps workspaces are automatically removed based on the timeout configured via the
teamcity.tfs.workspace.idleTime build agent property set to the default value of 1209600 sec (2 weeks).
Enforce overwriting all files.
When this option is enabled, TeamCity will call Azure DevOps to update the workspace rewriting all files.
Normally, there is no need to do a forced update for every build. If you suspect that TeamCity is not getting the latest version from the repository, you can use this option.
Azure DevOps does not allow several workspaces on a machine mapped to the same directory. If it happens, the TeamCity Azure DevOps agent-side checkout will attempt to remove intersecting workspaces to create a new workspace that matches the specified VCS root and checkout rules.
Note that it can fail to remove workspaces created by another user. In this case, you need to remove such workspaces manually.
To differentiate local mappings, it is recommended to use checkout rules in the following format:
$/root1 => /root1
$/root2 => /root2
Authentication in Azure DevOps
Azure DevOps stopped supporting alternate credentials since March 2, 2020. Currently, only authentication via personal access tokens is available.
Personal access tokens can be issued in the corresponding section of your Azure DevOps account. Set the Code access scope to All scopes in the repositories you are about to access from TeamCity.
After the token is issued, copy and paste it to the Password field of your VCS root settings. Leave the Username field empty — you should specify the username only if you are using older versions of Azure DevOps that still support authentication to TFVC repositories via regular username/password credentials.
NTLM/Kerberos on Linux and macOS
To use this authentication method, check that your machine includes Kerberos libraries and that the authentication is properly configured. If you encounter any issues, please check the steps described in the Microsoft documentation.
Azure DevOps Proxy Configuration
HTTP Proxy Server Configuration
Default .NET Working Mode
To interact with the Azure DevOps Server, the proxy server settings specified for the user account which runs the TeamCity server or agent will be used.
Cross-Platform Working Mode
The default Java proxy server settings specified for the TeamCity server or agent will be used in the Azure DevOps integration. On the TeamCity server, internal properties or Java options can be used. On the TeamCity agent, build agent configuration or Java options can be used. The TeamCity-TFS integration supports the following options: