Azure DevOps
TeamCity can connect to repositories in a version control system of Microsoft Azure DevOps Server (formerly, Team Foundation Server), or Azure DevOps Services.
This article contains descriptions of the fields and options available when setting up a Team Foundation Server VCS root type that is responsible for connecting Azure DevOps projects. Common VCS root properties are described here.
This type of root allows connecting to TFVC repositories only. When connecting to an Azure DevOps Git repository, select the Git type.
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%
To enforce the cross-platform mode, set the teamcity.tfs.mode=java build configuration parameter.
Settings
Setting | Description |
|---|---|
URL | The Server URL in the following format:
|
Root | Specify the root directory using the following format: |
Username | 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). |
Password | Enter the user's password. |
Agent-Side Checkout
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 local or server.
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).
Setting | Description |
|---|---|
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
The following authentication options are available in Azure DevOps.
Personal Access Tokens
When connecting to a TFVC repository, leave the Username field in the VCS root settings empty and specify your access token as Password.
You can create a personal access token (PAT) in your Azure DevOps account.
Set the Code access scope to All scopes in the repositories you are about to access from TeamCity.
Refreshable Access Tokens
This option is available if the VCS root was configured using an Azure DevOps OAuth 2.0 connection. In this case TeamCity uses an OAuth application to issue short-lived tokens instead of passwords or PATs. See this help article for more information: Authentication Settings.
Alternate Authentication Credentials
Azure DevOps stops supporting alternate credentials since March 2, 2020. To be able to authenticate in Azure DevOps, please use other methods instead (such as personal access tokens).
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
To enable usage of Azure DevOps Proxy, define the TFSPROXY environment variable for the user account which runs the TeamCity server or agent and restart them to apply changes.
Example:
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 agent will be used in the Azure DevOps integration. On the TeamCity agent, build agent configuration or Java options can be used. The TeamCity — Azure DevOps integration supports the following options: