现在可以在 Azure DevOps 中将 GitHub Secret Protection 和 GitHub Code Security 作为独立产品获取。 机密保护提供对机密扫描、推送保护和安全概述体验的访问权限。 代码安全性提供对所有依赖项扫描、代码扫描和安全概述体验的访问权限。
在测试计划中,我们将发布新的测试计划目录,以帮助你保持井然有序并节省时间。 现在可以更高效地管理测试计划,更好地控制工作区并减少重复任务。
有关详细信息,请查看发行说明。
适用于 Azure DevOps 的 GitHub Advanced Security
概况
- 限制个人访问令牌 (PAT) 创建的组织策略现已进入公开预览阶段
- 删除过期的 Azure DevOps OAuth 应用
- 新的 Microsoft Entra OAuth 范围
- 请求访问 URL 可用性
Azure Pipelines
Azure Test Plans
适用于 Azure DevOps 的 GitHub Advanced Security
GitHub 高级安全性现已以 GitHub 机密保护和代码安全形式适用于 Azure DevOps
GitHub 机密保护和 GitHub Code 安全性现在可以作为 Azure DevOps 上的独立产品购买,供新客户使用。
机密保护提供对机密扫描、推送保护和安全概述体验的访问权限。 代码安全性提供对所有依赖项扫描、代码扫描和安全概述体验的访问权限。
所有现有的高级安全客户都可以继续使用捆绑产品体验,而不会中断。 如果你是当前的高级安全客户,并且有兴趣切换到独立产品,请通过 Azure 门户联系 Azure DevOps 支持人员。 可以为 Azure DevOps 服务的 GitHub 高级安全性提交支持票证,并选择 Billing migration from bundled to standalone products 为问题类型。
有关这些产品的详细信息,请参阅 开发人员博客。
概况
限制个人访问令牌 (PAT) 创建的组织策略现已进入公开预览阶段
我们在 Azure DevOps(限制个人访问令牌(PAT)创建中引入了新的组织级策略,现已在公共预览版中提供。 此长期请求的功能允许项目集合管理员控制谁可以创建或重新生成 PAT,帮助减少令牌蔓延并提高安全性。 启用后,仅允许列表中的用户生成 PAT,并可选支持打包范围。 除非明确允许,否则策略还会阻止全局 PAT 使用。 在 博客文章中详细了解此策略和实现此更改的最佳做法!
删除过期的 Azure DevOps OAuth 应用
为 2026 年 Azure DevOps OAuth 应用的生命周期做准备时,我们将开始定期删除具有六个多月前(180 天前)过期的机密的应用。 这些非活动应用的所有者将收到通知,如果在现在和 Azure DevOps OAuth 于 2026 年终止之间的任何时间需要进行应用注册,我们会要求您在 6 月 9 日之前更换应用机密,因为我们将在这之后开始删除应用。 在我们的博客文章中了解详细信息。
新的 Microsoft Entra OAuth 授权范围
Azure DevOps 引入了两个新的 Microsoft Entra OAuth 范围(vso.pats 和 vso.pats_manage),以增强对个人访问令牌(PAT)生命周期管理 API 的安全性和控制。 这些权限范围现已用于涉及 PAT 创建和管理的委托流,取代了之前广泛使用的 user_impersonation 范围。 此更改使应用所有者能够减少应用访问 PAT API 所需的权限。 将 user_impersonation 应用的范围限制到当前所需的最低程度!
请求访问 URL 可用性
Azure DevOps 管理员可以禁用 请求访问 策略,并为用户提供 URL 以请求对组织或项目的访问权限。 此 URL(之前仅向新用户提供)现在也会在 404 页面上显示给现有用户。 为了保持保密性,无论项目是否存在,都会显示请求访问 URL。
Azure Pipelines
托管 DevOps 池 - 镜像弃用
由于 Windows Server 2019 托管映像的弃用和 Ubuntu 20.04 的弃用,托管 DevOps 池将弃用“Azure Pipelines – Windows Server 2019”映像和 Ubuntu 20.04 映像。 有关弃用的更多详细信息,请参阅此处。 可以在此处阅读关于托管 DevOps 池提供的映像生命周期信息。
新的触发器页
YAML 管道提供了多个强大的选项,用于定义管道何时应运行。 如果管道配置为在事件发生时运行(例如,送料管道已完成),那么要判断是否需要运行该管道并不总是容易的。
在冲刺中,我们将推出一个触发器页,该页可让你查看在管道中已定义的触发器。
假设你在一个代码仓库的 main 分支中定义了以下 YAML 管道。 考虑还有一个具有相同 YAML 管道代码的 feature 分支。
trigger:
- main
schedules:
- cron: 0 0 * * *
always: true
displayName: Nightly build
branches:
include:
- main
resources:
pipelines:
- pipeline: FabrikamFiber
source: FabrikamFiber
trigger: true
导航到 “触发器 ”页时,会看到以下内容
请注意,管道的默认分支main已被预先选择。
可以看到此分支存在 持续集成触发器 ,并且已在 YAML 文件中定义。
导航到 计划触发器时,可以看到定义了触发器,可以看到其详细信息。
导航到 “资源触发器 ”部分时,会看到定义的资源触发器及其详细信息。
你可以在分支之间切换,从main到feature,以查看你为feature分支定义的触发条件。
在 “资源触发器 ”选项卡中,当不在默认分支上时,会收到一条警告,告知你为此分支定义的触发器将被忽略。
当系统未正确处理触发器定义时,会收到有关如何解决问题的警告和指示。
StringList 参数类型
开发人员社区中请求最多的 YAML 管道功能之 一是定义包含项列表的参数。
从此次迭代开始,我们添加了一种名为StringList的新参数类型,该类型提供了此功能。
假设你希望允许执行管道运行排队的人员来选择要在其中部署有效负载的区域, 现在你可以这样做,就像下面的例子所示。
parameters:
- name: regions
type: stringList
displayName: Regions
values:
- WUS
- CUS
- EUS
default:
- WUS
- CUS
- EUS
stages:
- ${{ each stage in parameters.regions}}:
- stage: ${{stage}}
displayName: Deploy to ${{stage}}
jobs:
- job:
steps:
- script: ./deploy ${{stage}}
在对此管道进行排队时,你可以选择要部署到的多个区域,如下面的屏幕截图所示。
注释
该 stringList 数据类型在模板中不可用。 请改用 object 模板中的数据类型。
查看管道运行的完整 YAML 代码
YAML 管道是可组合的。 可以扩展模板,以确保管道运行必要的静态分析工具,并包括用于运行常见阶段或作业或任务的模板。
调试此类管道并不容易,因为看不到它正在运行的完整 YAML 代码。
假设你有以下管道:
parameters:
- name: PoolName
type: string
default: Azure Pipelines
- name: VmImage
type: string
default: ubuntu latest
extends:
template: security-enforcing-template.yml
parameters:
jobs:
- template: job.monitoring.yml
- template: job.build.yml
parameters:
PoolName: ${{parameters.PoolName}}
VmImage: ${{parameters.VmImage}}
此处使用了三个模板。 每个模板都可以根据参数和变量值使用条件表达式来确定要运行的实际作业或步骤。
此外,查看过去的管道运行时,无法确定管道的代码现在是否与当时一致。
在此冲刺中,我们将添加一项新功能,使你能够轻松查看管道运行的完整 YAML 代码。
Azure Test Plans
新测试计划目录介绍
使用新的测试计划目录保持井然有序并节省时间。 我们引入了多项增强功能,可帮助你更高效地管理测试计划,从而更好地控制工作区并减少重复任务。
新增功能如下:
更简洁的 UI 设计:使用新式界面轻松导航测试计划,可提高可读性并减少混乱,使你能够专注于任务而不分散注意力。
列排序:根据名称、状态或其他键属性对列进行排序,从而更快地找到所需的内容。 此功能可帮助你快速组织和确定测试计划的优先级,以提高工作效率。
“所有”选项卡中的团队筛选器:通过按团队筛选测试计划来专注于重要事项,确保只看到符合工作和目标的相关计划。
持久筛选器:使用记住设置的持久性筛选器节省时间。 返回到页面时,以前应用的筛选器将保持不变,提供有条理的视图,而无需每次重新应用筛选器。
这些更新旨在简化工作流、减少重复任务,并更轻松地跟踪和管理测试计划。 尝试一下,并通过电子邮件告诉我们你的想法吧!
高级测试用例结果历史记录
使用测试用例结果页的新增强功能轻松跟踪关键测试运行详细信息。 你将在页面上直接看到运行 ID、管道 ID、所有者、迭代路径和区域路径等关键信息,从而能够一目了然地获得每次测试运行的完整视图。
我们添加了长度较大的值和可自定义列的横向滚动功能,使你能够个性化布局,并在用户级别保存个人偏好设置。 为了帮助你更快地操作,运行 ID 和行均可单击,这让你可以快速访问测试运行视图,以获取更深入的见解。 这些更新旨在提高可见性、节省时间和简化工作流,从而更轻松地跟踪和管理测试运行。 请尝试一下,如果你有任何反馈,请通过 电子邮件 告知我们。 我们期待您的反馈!
在“执行”选项卡中查看测试用例状态
现在可以将“测试用例状态”列添加到“执行”选项卡,快速查看每个测试用例的状态。 无论是“已批准”、“正在进行”或任何其他状态,此更新都允许你更清楚地了解测试就绪情况,而无需切换浏览器选项卡或运行复杂的查询。
该列是可选的,可以通过列选取器启用。 它还与现有的状态筛选器保持一致,使你可以并排筛选和查看测试用例状态,所有这些状态都位于一个位置。
此增强功能有助于确保测试人员开始使用真正就绪或批准的测试用例,降低运行不完整或草稿项目的风险,并使测试从一开始就更高效地运行。
暂停测试用例的默认恢复
只需单击一下即可快速恢复暂停的测试用例。 我们已将“恢复”设为暂停测试用例的默认操作,使你能够继续您之前的操作,无需额外的导航。 通过此更新,可以更快、更轻松地继续工作,而不会中断。
为了进一步保护进度,我们引入了一个确认提示,以防止意外覆盖暂停的测试进度。 此安全措施可确保部分保存的工作保持完整,让您在管理测试运行时更安心。 尝试一下,并通过电子邮件告诉我们你的想法吧!
后续步骤
注释
这些功能将在未来两到三周内推出。 请去 Azure DevOps 上看看。
如何提供反馈
我们很乐意听到你对这些功能的看法。 使用帮助菜单报告问题或提供建议。
你还可以在 Stack Overflow 上获取社区的建议和问题解答。