| 开发人员社区 | 系统要求和兼容性 | 许可条款 | DevOps 博客 | SHA-256 哈希 |
在本文中,你将找到有关 Azure DevOps Server 最新版本的信息。
若要详细了解如何安装或升级 Azure DevOps Server 部署,请参阅 。
若要下载 Azure DevOps Server 产品,请访问 Azure DevOps Server 下载页。
Azure DevOps Server 2019 或 Team Foundation Server 2015 或更高版本支持直接升级到 Azure DevOps Server。 如果 TFS 部署在 TFS 2013 或更早版本上,则需要在升级到 Azure DevOps Server 2022 之前执行一些临时步骤。 有关详细信息,请参阅 “安装”页 。
Azure DevOps Server 发布日期:2025 年 12 月 9 日
Azure DevOps Server RTW 是支持 SQL Server 2025 的 bug 修复和更改的汇总。 它包括以前发布的 Azure DevOps Server RC 中的所有功能。
可以直接安装 Azure DevOps Server 或从 Azure DevOps Server 2022、2020、2019 或 Team Foundation Server 2015 或更高版本升级。
Azure DevOps Server RTW 中的新增功能摘要
- 合并的本地化更改。
- 更改以支持 SQL Server 2025。
- 修复了“仪表板”页面上“代码块”小组件配置中的问题,其中长存储库或分支名称超出了下拉列表控件的边界。
- 修复了在使用 webhook 时,GitHub PR 状态错误地保存为已关闭的问题,即合并和未合并的拉取请求都被标记为已关闭。 系统现在依赖于 Webhook 负载中的布尔合并标志,以准确记录数据库中的正确状态。
- 修复了导致 Visual Studio 在工作项跟踪 (WIT) 链接场景中挂起的递归属性问题。
- 解决了“收集设置”下的“代理池”页引发错误,并在分析暂停或禁用时无法加载的问题。 无论分析状态如何,页面现在都会正确加载。
Azure DevOps Server RC 发布日期:2025 年 10 月 7 日
Azure DevOps Server RC 中的新增功能摘要
Azure DevOps Server 引入了以前在产品的托管版本中发布的功能。 可以跳转到各个部分,查看每个服务的所有新功能:
概况
将代码块复制到剪贴板
为了响应 开发人员社区中的反馈,我们引入了“ 复制到剪贴板 ”按钮,用于呈现的 Markdown 中的所有代码块。 此增强功能可用于 Wiki 页面、Repos 中的 Markdown 文件预览、拉取请求讨论和说明以及工作项讨论。
添加了“交付计划”权限
作为我们正在进行的安全增强的一部分,我们引入了新的“管理交付计划”项目级权限。 此更改已被实施,以防止读者组中用户意外进行读/写访问。
Boards
GitHub 拉取请求上的 AB# 链接
作为 Azure Boards + GitHub 集成的持续增强的一部分,我们很高兴推出一项新功能来简化 AB# 链接的显示方式。 通过此更新,AB# 链接现在直接显示在 GitHub 拉取请求 的开发部分中,使无需搜索说明或注释即可更轻松地访问链接的工作项。
仅当 AB# 包含在拉取请求说明中时,才会显示这些链接。 如果直接从工作项链接,它们将不会显示在“开发”部分中。 此外,从说明中删除 AB# 链接会将其从开发控件中删除。
连接到 GitHub 存储库搜索的改进
我们改进了将 Azure DevOps 项目连接到 GitHub 组织的过程,尤其有利于拥有数千个存储库的人员。 以前,你可能面临超时错误和长时间等待等挑战。 此更新优化了搜索和选择体验,消除了超时错误的风险,使连接过程更加顺畅、更高效。
GitHub 集成:显示 YAML 管道的生成状态
我们致力于在 YAML 和经典管道之间实现功能一致性。 缺少的关键功能之一是在 GitHub 中托管存储库时提供“在生成中集成”链接的能力。 在最新版本中,我们通过在 YAML 管道设置中添加一个选项来解决这一不足,供您核对。
生成完成后,相应的链接将自动显示在关联的工作项上,从而改善整体的可追溯性。
支持连接 GitHub 资源库的 REST API
我们引入了新的 REST API 终结点,使你能够自动在 Azure DevOps Projects 中添加和删除 GitHub 存储库。 此外,在使用这些终结点时,我们将每个连接的存储库限制从 500 增加到 2,000。
这些终结点包括:
我们还 提供了示例代码 来帮助你入门。
删除区域和迭代路径的更改
删除区域或迭代路径可能会造成干扰。 它可以将工作项移动到新的路径,并可能导致团队失去对董事会和积压工作的访问权限。 尽管出现警告和提示,但有时会删除路径,而不会完全理解后果。 为了解决此问题,我们更改了行为:仅当任何工作项不再使用区域和迭代路径时,才能删除它们。
工作项窗体上的增强标记管理
Azure Boards 中的标记管理已得到增强,以提供更简化的体验。 已删除的标记不再显示在工作项窗体的建议列表中,确保仅显示活动标记。
改进工作项目注释中的图像支持
我们改进了将图像粘贴到工作项批注中的支持。 现在可以将图像直接从Microsoft Teams、电子邮件和 Word 文档等源粘贴到工作项的讨论部分
关于工作项注释的 REST API 限制
为了增强安全性,已对可通过 REST API 添加到工作项的注释数设置新的限制。 每个工作项现在通过 API 最多支持 1,000 条注释。 此限制仅适用于 REST API,用户仍可以通过 Web 界面手动添加注释,甚至超出 1,000 注释阈值。
增大交付计划限制
我们已将每个项目的交付计划的最大数量从 1,000 增加到 1,500。
Repos
禁止创建 TFVC 资源库的新设置
近年来,Team Foundation 版本控制(TFVC)中没有新增功能,因为 Git 已成为 Azure Repos 中的首选版本控制系统。 最近,所有安全性、性能和辅助功能方面的改进仅针对 Git 存储库进行,这导致 TFVC 使用量持续下降。 虽然有些人仍依赖于 TFVC,我们不打算删除这一功能集,但我们计划对于新项目和项目集合,以及当前不使用 TFVC 的项目,逐步淘汰 TFVC。
在此转换过程中,我们将引入一个新设置“禁用创建 TFVC 存储库”,这只会影响新 TFVC 存储库的创建,不会影响现有存储库。
Git 子模块的 UI 支持
许多团队积极使用 Git 子模块来组织其基本代码。 我们很高兴地分享我们在文件中心添加了对 Git 子模块的支持。 现在,只需单击一下即可导航到子模块存储库,只需单击一下,即可完全导航到从超级项目引用的特定提交。 用作子模块时,支持以下 Git 服务:Azure Repos、GitHub、GitLab 和 Bitbucket。 也支持 .gitmodules 文件中指定的多个 URL 格式,包括绝对 HTTPS、SSH 和相对 URL。
存储库文件中心的新“运行状况和使用情况”面板
随着 Git 存储库的增长,它们会累积提交、Blob 和其他数据,从而增加 Azure DevOps 基础结构上的负载,从而影响性能和用户体验。 维护正常的存储库是确保一致性能和可靠性的关键。
为了支持此功能,我们现在监视多种因素,例如存储库大小、提交频率、内容和结构。 如果存储库开始使基础结构紧张,则你可能会收到一条包含纠正措施建议的通知。 通过管理存储库的运行状况,可以防止中断并确保顺利运行。
若要检查存储库的运行状况,请转到 Azure Repos、文件, > 然后从省略号菜单中选择“运行状况和使用情况”,以访问存储库运行状况和使用情况面板。
为拉取请求配置目标分支
管理存储库中的多个分支可能非常困难,尤其是在创建新的拉取请求时。 使用新的“为拉取请求配置目标分支”功能,现在可以指定首选目标分支的列表,确保拉取请求建议更准确且更相关。 这有助于简化工作流,并减少针对错误分支的可能性。 若要使用此功能,请在存储库的默认分支中创建 .azuredevops/pull_request_targets.yml 文件。 此 YAML 文件应包含标题为pull_request_targets的列表,其中包含与候选分支匹配的分支名称或前缀。 例如:
pull_request_targets:
- main
- release/*
- feature/*
在此配置中,主分支优先,但以 release/ 或 feature/ 开头的分支也会视情况而定地考虑。 配置在以下方案中应用:
- 拉取请求建议:将分支推送到 Azure DevOps 后,Repos 页可能会建议从该分支创建拉取请求,从而动态选择目标分支。
- 拉取请求 URL:使用 sourceRef 参数直接导航到拉取请求创建页面但省略 targetRef 参数时,Azure DevOps 会基于此动态选择选择目标分支。
建议仅包含受拉取请求策略保护的分支,以确保提示提交的第一个父历史记录中的一致性。
支持 markdown 文件中的美人鱼图
包含美人鱼语法的 Markdown 文件现在将在存储库文件浏览器和拉取请求的文件预览中呈现为关系图。 这有助于将更丰富的文档添加到存储库。
用于演示在 Markdown 文件中对 mermaid 图表支持的图像
在 PR 列表页上按标题搜索拉取请求
拉取请求列表页面现在包含按 PR 标题筛选的筛选器,以便更轻松地查找特定的拉取请求。
Azure Repos 的稀疏签出
YAML 签出任务现在支持 git 稀疏签出 命令,与 部分克隆筛选器一起,以提高存储库签出性能。 可以使用名为 sparseCheckoutDirectories 和 sparseCheckoutPatterns 的属性。
设置 sparseCheckoutDirectories 可启用 cone mode,通过目录匹配来执行签出过程。 或者,您可以设置 sparseCheckoutPatterns,以触发非锥形模式,从而允许更复杂的模式匹配。
如果设置了这两个属性,代理会使用目录匹配初始化圆锥模式。 如果在签出任务中未指定这两个属性,则会禁用稀疏签出过程。 在命令执行过程中遇到的任何问题都会导致签出任务失败。 稀疏签出锥模式的 YAML 示例:
checkout: repo
sparseCheckoutDirectories: src
YAML example for sparse checkout non-cone mode:
YAMLCopy
checkout: repo
sparseCheckoutPatterns: /* !/img
重要
稀疏签出功能需要代理 v3.248.0(适用于 .NET 8 的 v4.248.0)或更高版本。
可以在 发布页上找到代理。
使跨存储库策略区分大小写
以前,跨存储库策略中的分支候选预览会以不区分大小写的方式显示结果,尽管分支匹配是区分大小写的。 这种不一致带来了潜在的问题,因为某些分支看起来像是受到了保护,但实际上并没有。 为了解决这一问题,我们更新了分支模式预览,使其与策略应用程序区分大小写的行为保持一致。
以前:
After:
TFVC 签入策略更改
Microsoft.TeamFoundationServer.ExtendedClient NuGet 包的新版本 (19.254)
NuGet Microsoft.TeamFoundationServer.ExtendedClient 包已更新为新的 TFVC 策略类和方法。
策略更改
我们正在对 Azure DevOps 中存储 TFVC 签入策略的方式进行更改,这也意味着 NuGet Microsoft.TeamFoundationServer.ExtendedClient 如何与服务通信的更新。 如果 TFVC 项目使用签入策略,请将这些策略迁移到新格式。 可以通过两种方式来执行此操作:
- 使用 Visual Studio。
警告
在执行此操作之前,请确保已将 Visual Studio 更新到最新版本(确保VS 2022、VS 2019 和最低版本的 VS 2017 已更新到 17.14 预览版 3、17.13.6、17.12.7、17.10.13、17.8.20、16.11.46、15.9.72,以支持新政策)。
若要使用 Visual Studio 项目管理员创建新策略,应打开设置 - 团队项目 ->> 源代码管理 -> 签入策略并添加新策略(没有“已过时”标记),其参数与旧策略相同:
- 如果使用 Microsoft.TeamFoundationServer.ExtendedClient 的自定义实现来与服务器通信,请按照 迁移指南进行作。 迁移需要使 TFVC 签入与将来的 Azure DevOps 版本兼容。 目前,旧策略(已过时)和新策略仍然有效且功能正常。 有关未来计划的信息,请参阅我们的 博客文章。
增强 GetRepository API 功能
我们已将 creationDate 属性添加到存储库响应 - 获取存储库 API 返回存储库创建日期。 该属性在 API 版本 7.2-preview 及更高版本上可用。
拉取请求查询 API 的增强功能
我们在拉取请求查询 - 获取 API 的响应中引入了新的 Label 属性。 现在可以指定是否在每个查询中包含相关拉取请求的标签(标记)。 新的 Include 属性可用 - 如果设置为“标签”,响应将包含指定 PR 的标签。 如果保留为 null,则不会包含标签。 若要防止意外错误,请确保不应显式分配 NotSet - 这将导致错误的请求。
注释
标签扩充资源利用率取决于分配的标签数及其长度。 请求标签可能会导致影响速率限制并增大网络负载。 为了优化性能,我们建议避免不必要的标签请求。
请求负载示例:
{
"queries": [
{
"type": "lastMergeCommit",
"include": "Labels",
"items": [
"0d6c9b2b524113113fced41aecbf8631a4649dec"
]
},
{
"type": "lastMergeCommit",
"items": [
"b524113113f0dd41aecbf8631a4649dec6c9b2ce"
]
}
]
}
Pipelines
TFX 验证任务是否正在使用生命周期结束的节点运行器
任务作者使用 TFX 发布扩展。 TFX 已更新为在其他节点运行程序版本上执行验证。
包含使用已到达生命周期终点的Node版本(包括Node 16)的任务的扩展将显示如下警告:
任务 < 任务名称 > 依赖于一个任务运行程序,该运行程序是生命周期结束的,并且将来会被删除。 作者应查看节点升级指南: https://aka.ms/node-runner-guidance
使用 Microsoft Entra ID 身份验证从管道访问 Azure 服务总线
现在可以使用 Microsoft Entra ID 身份验证 从 Azure Pipelines 访问 Azure 服务总线。 这样就可以利用 Azure RBAC 进行精细的访问控制。
需要将访问 Azure 服务总线的标识授予服务总线的一个 Azure 内置角色。
PublishToAzureServiceBus@2 任务
可以使用 Azure 服务连接配置新的PublishToAzureServiceBus@2任务。 创建 Azure 服务连接 并填充新任务的 serviceBusQueueName 和 serviceBusNamespace 属性:
- task: PublishToAzureServiceBus@2
inputs:
azureSubscription: my-azure-service-connection
serviceBusQueueName: my-service-bus-queue
serviceBusNamespace: my-service-bus-namespace
useDataContractSerializer: false
messageBody: |
{
"foo": "bar"
}
服务器任务
使用 ServiceBus 执行的自定义服务器(无代理)任务可以将 Azure 服务连接指定为 EndpointId,并省略 ConnectionString。 请参阅 服务器任务创作。
TFX 验证任务是否正在使用生命周期结束的节点运行器
任务作者使用 TFX 发布扩展。 TFX 已更新为在其他节点运行程序版本上执行验证。
包含使用已到达生命周期终点的Node版本(包括Node 16)的任务的扩展将显示如下警告:
任务 < 任务名称 > 依赖于一个任务运行程序,该运行程序是生命周期结束的,并且将来会被删除。 作者应查看节点升级指南: https://aka.ms/node-runner-guidance
使用生命周期结束节点运行程序版本执行的任务会发出警告
不再受支持的 Node 版本上运行的管道任务将开始接收到警告:任务_TaskName_版本依赖于已停止支持的 Node 版本(10)。 请联系扩展所有者获取任务的更新版本。 任务维护人员应查看节点升级指南: https://aka.ms/node-runner-guidance 若要取消这些警告,可以在管道(作业)或任务级别设置环境或管道变量。 例如:
variables:
AZP_AGENT_CHECK_IF_TASK_NODE_RUNNER_IS_DEPRECATED: false
DockerCompose@0 在 v1 兼容模式下使用 Docker Compose v2
Docker Compose v1 将于 2024 年 7 月 24 日从托管代理中删除其生命周期结束。 如果 Docker Compose v1 在代理上不可用,我们已更新 了DockerCompose@0 任务,以在 v1 兼容模式下使用 Docker Compose v2。
但是,兼容性模式不能解决所有兼容性问题。 请参阅 “迁移到 Compose V2”。 某些用户需要更多的时间来更新其 Docker Compose 项目,以便实现 Docker Compose v2 兼容性。 在这些情况下,请按照这些说明将 DockerComposeV0 任务与 docker-compose v1 配合使用。 注意:本指南基于安装 Compose 独立文档,在 Windows 上使用 docker-compose v1 将 powershell 步骤添加到管道,以下载 docker-Compose v1.29.2,并将其与 Windows 上的 DockerComposeV0 任务配合使用:
variables:
dockerComposePath: C:\docker-compose
steps:
- powershell: |
mkdir -f $(dockerComposePath)
# GitHub now requires TLS1.2. In PowerShell, run the following
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Start-BitsTransfer -Source "https://github.com/docker/compose/releases/download/1.29.1/docker-compose-windows-x86_64.exe" -Destination $(dockerComposePath)\docker-compose.exe
displayName: Download docker-compose
- task: DockerCompose@0
inputs:
containerregistrytype: 'Azure Container Registry'
dockerComposeFile: '**/docker-compose.yml'
action: 'Run a Docker Compose command'
dockerComposeCommand: 'run'
dockerComposePath: $(dockerComposePath)\docker-compose.exe
Use docker-compose v1 on Linux
Add the bash step to your pipeline to download Docker-Compose v1.29.2 and use it with the DockerComposeV0 task on Linux:
YAMLCopy
variables:
dockerComposePath: /tmp/docker-compose
steps:
- bash: |
sudo mkdir $(dockerComposePath)
sudo curl -SL https://github.com/docker/compose/releases/download/1.29.2/docker-compose-linux-x86_64 -o $(dockerComposePath)/docker-compose
sudo chmod 755 $(dockerComposePath)/docker-compose
displayName: Download docker-compose
- task: DockerCompose@0
inputs:
containerregistrytype: 'Azure Container Registry'
dockerComposeFile: $(Build.SourcesDirectory)/DockerComposeV0/docker-compose.yml
action: 'Run a Docker Compose command'
dockerComposeCommand: 'run'
dockerComposePath: $(dockerComposePath)/docker-compose
Test Plans
清单文件 V3 中的测试和反馈扩展
我们很高兴地宣布对 Chrome 和 Edge 的 Azure DevOps 测试和反馈扩展进行新的更新。 此更新根据 Google 的清单 V2 弃用计划将实现从清单 V2 转换到 V3。 虽然扩展的核心功能保持不变,但更新可增强安全性和性能。
有关更多详细信息,请查看我们最近关于此更新的博客文章。 清单 V3 中的测试和反馈扩展
Azure 测试运行程序版本 1.2.2
Azure 测试计划在 1.2.2 中发布了一个修补程序,该修补程序适用于测试计划中的最新问题,其中 Azure 测试运行程序(ATR)在 Chrome 版本 130 中遇到启动失败。 此问题是由于 Chrome 添加了 对非特殊方案 URL 的支持,这影响了 ATR 用户流。 更新后,将解决回归 bug,并还原 ATR 功能。 有关此回归 bug 的更多详细信息,请访问 Chromium 中的 此问题跟踪器 。
建议使用 Web 应用程序增强功能。 如果你在 Web 应用程序中发现任何缺失的功能,我们很乐意听到你的声音。 与我们分享你的反馈 !
用于测试用例执行的无缝生成管道集成
通过无缝集成生成管道配置,我们简化了测试用例执行过程。 在测试计划级别设置的生成定义和 ID 现在会自动传播到 Web 运行程序,无需每次手动配置。 这种改进可节省时间并提高效率,使你能够专注于更关键的任务。
使用 REST API 还原已删除的测试计划和测试套件
使用新的自助服务 API 轻松还原已删除的测试计划和测试套件。 我们引入了 GET 和 PATCH API,使你能够查找已删除的测试计划或套件,并连同其子项一起还原它们,而无需客户支持。 使用这些 API,可以快速恢复意外删除的测试工作项,减少停机时间并提高工作效率。 虽然不会还原运行项目,但所有相关的测试计划、套件和测试用例都可以轻松返回到工作区。 此自助服务功能可更好地控制测试管理并简化还原过程,使恢复关键测试资产更快、更高效。
在 XLSX 中使用自定义列导出测试用例
现在可以在 XLSX 中使用自定义列导出测试用例。 根据反馈,测试计划支持使用自定义列导出测试用例,从而更好地灵活地控制共享和分析的数据。 此增强功能可帮助你根据需要定制导出,确保导出的信息相关且可作。
测试计划目录中的新增排序功能
测试计划目录现在提供增强的排序选项! 通过此更新,可以快速按字母顺序组织每个列,从而提供一种简化的方式来查找和访问数据。
撤销网络和桌面运行程序中的测试步骤
使用新的“撤消”选项控制测试用例运行。 可以使用简单的双击轻松还原测试步骤状态,从而在测试运行期间获得更大的灵活性和控制。 现在,无需通过重启测试用例来修复意外点击,只需撤消,继续工作流即可,不会受到干扰。
我们还引入了键盘友好的导航功能和无障碍功能改进,以确保此功能能够无缝地为所有用户服务,包括依赖辅助技术的用户。 此增强功能可帮助你节省时间、减少挫折感,并专注于高效运行测试。
发布代码覆盖率结果 v2 任务改进
在此版本中,我们将包括对 v2 任务的多项改进:
扩展了对各种代码覆盖率格式的支持,包括:.coverage、.covx、.covb、.cjson、.xml、.lcov 和 pycov1。
生成全面的 cjson 文件(和代码覆盖率报告),其中包含详细的代码覆盖率信息,例如文件名、涵盖/未涵盖的行等。
支持差异覆盖率(PR 覆盖率):v2 可以在同一管道中为多种语言生成差异覆盖率的 PR 评论。
v2 任务现在支持生成质量检查任务,该任务在 v1 任务中不受支持。
测试计划中对 YAML 管道的支持
除了经典管道,现在还可以在配置测试计划或从测试计划执行自动测试时使用 YAML 管道。
此请求的优先级是基于以下开发者社区反馈票证。
报告
待办事项中可以使用的汇总列数据
我们更新了汇总列以显示最新的可用数据。 以前,对于频繁更新的工作项,这些列可能显示为空白,从而导致混淆。 你还将看到一个时间戳,指示上次刷新数据的时间。 虽然分析处理中的一些延迟是正常的,但在处理汇总列时,这些改进旨在提供透明度,和更流畅的体验。
维基
改进将基于 HTML 的内容粘贴到 Wiki
我们已更轻松地将基于 HTML 的内容粘贴到 Wiki 中。 现在,链接、列表、表、图像、Excel 工作表、Microsoft Teams 消息、电子邮件和 Azure 数据资源管理器查询等 HTML 元素会自动转换为 Markdown 语法,以便更流畅地进行编辑。