Azure DevOps 服务更新和集成改进

为了帮助确保 Azure DevOps 环境保持安全,我们正在进行关键服务更新。 这包括从 2025 年 4 月开始终止对新 OAuth 应用注册的支持,尽管现有应用将继续工作,直到 2026 年完全停用。 此外,从 2025 年 4 月 23 日开始,所有 HTTPS 连接都需要服务器名称指示(SNI),以及 Azure Repos 中 TFVC 签入策略的更新。

除了这些更新之外,我们很高兴地宣布 Azure Boards + GitHub 集成的最新改进,以便更轻松地链接分支、拉取请求和提交工作项。 此外,管道现在提供对 YAML 阶段依赖项的更深入的可见性,帮助团队以提高效率管理更复杂的工作流。

有关详细信息,请查看发行说明。

概况

Azure Boards:

Azure Repos

Azure Pipelines(Azure 管道服务)

Azure 测试计划:

概况

从 2025 年 4 月开始,没有新的 Azure DevOps OAuth 应用

从 2025 年 4 月开始,我们不再支持 Azure DevOps OAuth 应用的新注册。 这是我们实现停用 Azure DevOps OAuth 平台的长期愿景的第一步。 我们建议所有在 Azure DevOps REST API 上构建应用程序的开发人员探索 Microsoft 标识平台并改为注册新的 Entra 应用程序

所有现有的 Azure DevOps OAuth 应用将继续运作,直到平台在 2026 年正式停用。 在此处的博客文章中了解详细信息。

Azure DevOps Services 现在强制使用服务器名称指示 (SNI)

从 2025 年 4 月 23 日开始,我们将要求对所有到 Azure DevOps Services 的传入 HTTPS 连接使用 服务器名称指示(SNI )。

SNI 是 TLS 协议的扩展,允许客户端指定要连接到的主机名。 所有新式浏览器和客户端软件都支持 SNI,并默认使用它,确保大多数用户无缝过渡。 事实上,到达我们服务器的 99.995% 以上的客户流量支持 SNI。

但是,由于各种因素(例如过时、配置错误的网络库、运行时或作系统),某些客户端软件可能与 SNI 不兼容。 代理或 NGFW 防火墙也可能出现问题。 与 Azure DevOps 一起使用的以下工具可能会受到 SNI 问题的影响:

  • Git 客户端
  • IDE 插件和扩展(Team Explorer Everywhere)
  • 在旧版 Java 上运行的软件(不支持 SNI(Java 6 及更早版本)或默认情况下未启用 SNI(某些版本的 Java 7 和 8)
  • 旧浏览器版本(请参阅 https://caniuse.com/sni

SNI 问题通常由连接错误显示,例如:

  • ERR_SSL_PROTOCOL_ERROR、ERR_CERT_COMMON_NAME_INVALID
  • javax.net.ssl.SSLHandshakeException、javax.net.ssl.SSLException
  • 无法为 SSL/TLS 安全通道建立信任关系

可以通过调用 Azure DevOps 的状态终结点(我们配置为需要 SNI)来验证系统的 SNI 兼容性。 如果此调用成功,则表示主机(包括其作系统和网络环境)与 SNI 兼容。 有关如何测试的详细说明,请访问我们的 博客文章

Azure Boards

GitHub 集成:链接到提交、分支和拉取请求的改进

我们正在不断改进 Boards + GitHub 集成,以缩小可用性差距,并与你在 Azure Repos 中熟悉的体验保持一致。

通过此次更新,我们引入了几项改进,以简化分支、拉取请求和提交与工作项的链接方式:

  • 当一个 GitHub 分支被链接到一个工作项时,任何相关的拉取请求现在都会被自动链接。 无需手动使用 AB#。

  • 合并拉取请求后,合并提交会自动链接到此工作项。

  • 如果在合并拉取请求后删除分支,则分支链接将自动从工作项中删除。

通过这些改进,可以更轻松地跟踪开发进度并维持干净、最新的工作项关联。

针对 GitHub 板集成改进的 Gif。

GitHub 集成:显示 YAML 管道的生成状态

我们致力于在 YAML 和经典管道之间实现功能一致性。 缺少的关键功能之一是在 GitHub 中托管存储库时提供“在生成中集成”链接的能力。 在最新版本中,我们通过在 YAML 管道设置中添加一个选项来解决这一不足,供您核对。

生成完成后,相应的链接将自动显示在关联的工作项上,从而改善整体的可追溯性。

增大交付计划限制

以前,我们将每个项目的交付计划限制为 1,000 个。 通过此更新,我们已将每个项目的最大交付计划增加到 1,500 个。 可以在 此处的文档中了解有关添加和编辑传递计划的详细信息。

Azure Repos

TFVC 签入策略更改

Microsoft.TeamFoundationServer.ExtendedClient NuGet 包的新版本 (19.254)

NuGet Microsoft.TeamFoundationServer.ExtendedClient 包已使用新的 TFVC 策略类和方法进行更新。

策略更改

我们正在对 Azure DevOps 中存储 TFVC 签入策略的方式进行更改,这也意味着 NuGet Microsoft.TeamFoundationServer.ExtendedClient 如何与服务通信的更新。

如果 TFVC 项目使用签入策略,请将这些策略迁移到新格式。 可以通过两种方式来执行此操作:

  1. 使用 Visual Studio。

警告

在采取行动之前需要注意其可能带来的某些危险后果。在继续之前,请确保已将 Visual Studio 更新到最新版本(VS 2022、VS 2019 和 VS 2017,其中最低版本 17.14 Preview 317.13.617.12.717.10.1317.8.2016.11.4615.9.72 支持新策略)。

若要使用 Visual Studio 项目管理员创建新策略,应打开设置 - 团队项目 ->> 源代码管理 -> 签入策略并添加新策略(没有“已过时”标记),其参数与旧策略相同:

  1. 如果您使用自定义实现 Microsoft.TeamFoundationServer.ExtendedClient 来与服务器通信,请遵循 迁移指南进行操作。

迁移需要使 TFVC 签入与将来的 Azure DevOps 版本兼容。 目前,旧策略(已过时)和新策略仍然有效且功能正常。 有关未来计划的信息,请参阅我们的 博客文章

增强 GetRepository API 功能

我们已在存储库 - 获取存储库 API 的响应中添加了creationDate属性,以返回存储库创建日期。 该属性在 API 版本及更高版本 7.2-preview 上可用。

拉取请求查询 API 的增强功能

我们在请求查询 - 获取 API 的响应中引入了一个新 Label 属性。 现在可以指定是否在每个查询中包含相关拉取请求的标签(标记)。 新 Include 属性可用 - 如果设置为“标签”,响应将包含指定 PR 的标签。 如果保持为 null,则不会包含标签。 要防止出现意外错误,请确保未显式分配 NotSet,而它会导致 Bad Request

注释

标签扩充资源利用率取决于分配的标签数及其长度。 请求标签可能会导致影响速率限制并增大网络负载。 为了优化性能,我们建议避免不必要的标签请求。

请求有效负载示例:

{
    "queries": [
        {
            "type": "lastMergeCommit",
            "include": "Labels",
            "items": [ 
                "0d6c9b2b524113113fced41aecbf8631a4649dec"
            ]
        },
        {
            "type": "lastMergeCommit",
            "items": [
                "b524113113f0dd41aecbf8631a4649dec6c9b2ce"
            ]
        }
    ]
}

Azure Pipelines(Azure 管道服务)

改进了对 YAML 管道阶段依赖项的可见性

YAML 管道为管理复杂工作流提供了灵活性,但可视化阶段依赖项是一项挑战,尤其是在多区域部署中。

尚不清楚阶段之间如何连接。 例如,为了确定 CUS3 是否除了依赖 WUS2 和 WUS3 外还依赖于 WUS1,必须直接查看 YAML 文件。

在此冲刺中,当一个阶段被展开时,阶段依赖项现在便会进行显示,从而提供对执行顺序和上游要求的即时见解。

新建代理 CDN

由于 Edgio CDN 即将停用,Edgio https://vstsagentpackage.azureedge.net 拥有的域 URL 也将停用。 我们将添加新 CDN 支持的新域 URL https://download.agent.dev.azure.com 。 请务必将此新域 URL 添加到防火墙允许列表。 删除旧域 URL 后,自承载代理的代理包下载将失败。 有关更多详细信息,请参阅 文章

节点 16 将从管道-* 管道代理软件包中被移除。

代理任务可以在 PowerShell 或 Node 中实现。 代理附带了任务可作为目标的多个 Node 版本。

发布新的 Node 版本时, 任务 会更新为使用新的 Node 版本。 代理中包含运行时。

当 Node 版本退出上游维护时段时,某些管道任务仍依赖于它。 Azure DevOps 将受支持的任务更新到受支持的 Node 版本。 第三方任务可能仍需要较旧的 Node 版本才能运行。

为了适应这一点,我们有两种类型的管道代理

Node 版本 DESCRIPTION
vsts-agent-* 6, 10, 16, 20 包括可用作任务执行处理程序的所有 Node 版本
pipelines-agents-* 20 仅包括最新的 Node 版本。 这些包的目标是不包含 Node 的任何生命周期终止版本。

如果要在未捆绑 Node 16 的代理上运行需要 Node 16 执行处理程序的任务,可以通过在管道中插入 NodeTaskRunnerInstaller@0 任务来安装执行处理程序:

  steps:
  - task: NodeTaskRunnerInstaller@0
    inputs:
      runnerVersion: 16

Azure 测试计划

停用操作日志记录并改为屏幕录制

我们的桌面 Azure 测试运行程序客户端依赖于 问题步骤记录器 (PSR),这是 Windows 7 中引入的工具,现已在较新的 Windows 版本中 弃用 。 因此,在将来的更新中,桌面测试运行程序中的作日志功能可能不再有效。

为了确保测试跟踪不间断,我们建议切换到 Web 运行程序“ 测试与反馈扩展”中的屏幕录制,该扩展提供了一种现代、可靠的方法来捕获和管理测试步骤。 如果需要过渡到测试与反馈扩展的帮助,请联系我们的支持团队。

自动暂停手动测试运行

使用自动暂停测试用例运行的情况下,测试运行永远不会丢失进度。 如果工作中断,此新功能会自动暂停测试用例运行,确保保存部分进度而无需手动暂停。 无论是离开会话还是关闭会话,都可以在离开的位置轻松恢复测试用例,降低数据丢失的风险和改进工作流。 通过简化暂停和恢复过程,自动暂停可帮助你专注于测试,而无需担心丢失进度。 尝试一下,并通过电子邮件告诉我们你的想法吧!

Gif 用于演示 Web 和桌面运行程序中的撤销测试步骤。

后续步骤

注释

这些功能将在未来两到三周内推出。

请去 Azure DevOps 上看看。

如何提供反馈

我们很乐意听到你对这些功能的看法。 使用帮助菜单报告问题或提供建议。

提出建议

你还可以在 Stack Overflow 上获取社区的建议和问题解答。

谢谢

Silviu Andrica