Azure DevOps Server 2022 发行说明
| 开发者社区System 要求和兼容性 | 许可条款 | DevOps 博客 | SHA-256 哈希 | |
在本文中,你将找到有关 Azure DevOps Server 最新版本的信息。
若要详细了解如何安装或升级 Azure DevOps Server 部署,请参阅 Azure DevOps Server 要求。
若要下载 Azure DevOps Server 产品,请访问 Azure DevOps Server 下载页。
Azure DevOps Server 2019 或 Team Foundation Server 2015 或更高版本支持直接升级到 Azure DevOps Server 2022。 如果 TFS 部署在 TFS 2013 或更早版本上,则需要在升级到 Azure DevOps Server 2022 之前执行一些临时步骤。 有关详细信息,请参阅安装页。
Azure DevOps Server 2022 Update 0.1 修补程序 5 发布日期:2023 年 11 月 14 日
注意
如果未安装 Patch 3,则 Azure DevOps Server 修补程序是累积的,此修补程序包括对 Azure Pipelines 代理的更新。 安装 Patch 5 后的新版本为 3.225.0。
文件 | SHA-256 哈希 |
---|---|
devops2022.0.1patch5.exe | DC4C7C3F9AF1CC6C16F7562DB4B2295E1318C1A180ADA079D636CCA47A6C1022 |
我们发布了 Azure DevOps Server 2022 Update 0.1 的修补程序 ,其中包括以下修补程序。
- 扩展了 PowerShell 任务允许对 Enable shell 任务参数参数验证的字符列表。
- 修复了在单击“取消”按钮后导致服务连接编辑永久的问题。
Azure DevOps Server 2022 Update 0.1 修补程序 4 发布日期:2023 年 10 月 10 日
注意
如果未安装 Patch 3,则 Azure DevOps Server 修补程序是累积的,此修补程序包括对 Azure Pipelines 代理的更新。 安装 Patch 5 后的新版本为 3.225.0。
我们发布了 Azure DevOps Server 2022 Update 0.1 的修补程序 ,其中包括以下修补程序。
- 修复了升级管道执行模型导致管道停滞的 bug。
- 修复了修补程序升级计算机上“分析所有者”标识显示为非活动标识的 bug。
- 生成清理作业包含许多任务,每个任务都会删除生成的项目。 如果其中任一任务失败,则不会运行任何后续任务。 我们更改了此行为以忽略任务失败,并尽可能多地清理项目。
Azure DevOps Server 2022 Update 0.1 修补程序 3 发布日期:2023 年 9 月 12 日
注意
此修补程序包括对 Azure Pipelines 代理的更新。 安装 Patch 3 后代理的新版本将为 3.225.0。
我们发布了 Azure DevOps Server 2022 Update 0.1 的修补程序 ,其中包括以下修补程序。
- CVE-2023-33136:Azure DevOps Server 远程代码执行漏洞。
- CVE-2023-38155:Azure DevOps Server 和 Team Foundation Server 特权提升漏洞。
Azure DevOps Server 2022 Update 0.1 修补程序 2 发布日期:2023 年 8 月 8 日
我们发布了 Azure DevOps Server 2022 Update 0.1 的修补程序 ,其中包括以下修补程序。
- CVE-2023-36869:Azure DevOps Server 欺骗漏洞。
- 修复了 SOAP 调用中的 bug,其中可以针对大型元数据 XML 响应引发算术Exception。
- 实现了对服务连接编辑器的更改,以便在组件消除时刷新终结点状态。
- 解决了在 markdown 文件中无法工作的相对链接的问题。
- 修复了在定义了大量标记时,与应用程序层相关的性能问题,启动时间比正常时间长。
- 解决了代理池页上TF400367错误。
- 修复了分析所有者标识显示为非活动标识的 bug。
- 修复了 CronScheduleJobExtension 上的无限循环 bug。
Azure DevOps Server 2022 Update 0.1 修补程序 1 发布日期:2023 年 6 月 13 日
我们发布了 Azure DevOps Server 2022 Update 0.1 的修补程序 ,其中包括以下修补程序。
- CVE-2023-21565:Azure DevOps Server 欺骗漏洞。
- CVE-2023-21569:Azure DevOps Server 欺骗漏洞。
- 修复了服务连接编辑器中的 bug。 现在,组件消除时草稿终结点状态刷新。
- 修复了分离或附加集合失败并报告以下错误:“TF246018:数据库操作超出了超时限制并已取消。
Azure DevOps Server 2022 Update 0.1 发布日期:2023 年 5 月 9 日
Azure DevOps Server 2022.0.1 是 bug 修复的汇总。 它包括以前发布的 Azure DevOps Server 2022.0.1 RC 中的所有修补程序。 可以直接安装 Azure DevOps Server 2022.0.1 或从 Azure DevOps Server 2022 或 Team Foundation Server 2015 或更高版本升级。
Azure DevOps Server 2022 Update 0.1 RC 发布日期:2023 年 4 月 11 日
Azure DevOps Server 2022.0.1 RC 是 bug 修复的汇总。 它包括以前发布的 Azure DevOps Server 2022 修补程序中的所有修补程序。 可以直接安装 Azure DevOps Server 2022.0.1 或从 Azure DevOps Server 2022 或 Team Foundation Server 2015 或更高版本升级。
此版本包含对以下 bug 的修复:
- 已将 Git 虚拟文件系统(GVFS)从 v2.39.1.1-micorosoft.2 升级到解决安全漏洞。
- 测试数据未被删除,导致数据库增长。 通过此修补程序,我们更新了生成保留期,以防止创建新的孤立测试数据。
- AnalyticCleanupJob 更新,作业状态已停止,现在我们报告“成功”。
- 修复了“tfx extension publish”命令失败,并显示“字典中不存在给定密钥”错误。
- 实现了在访问团队日历扩展时解决和错误的解决方法。
- CVE-2023-21564:Azure DevOps Server 跨站点脚本漏洞
- CVE-2023-21553:Azure DevOps Server 远程代码执行漏洞
- 更新了 MSBuild 和 VSBuild 任务以支持 Visual Studio 2022。
- 更新加载重新身份验证的方法,以防止 XSS 攻击途径。
- Azure DevOps Server 2022 代理报告以下错误:VS800069:此服务仅在本地 Azure DevOps 中可用。
- 修复了通过 Web UI 解决货架集辅助功能问题。
- 解决了在更新 Azure DevOps Server 管理控制台中与 SMTP 相关的设置后,需要重启 tfsjobagent 服务和 Azure DevOps Server 应用程序池的问题。
- 在到期日期前七天未发送 PAT 通知。
Azure DevOps Server 2022 修补程序 4 发布日期:2023 年 6 月 13 日
我们发布了 Azure DevOps Server 2022 的修补程序 ,其中包括以下修补程序。
- CVE-2023-21565:Azure DevOps Server 欺骗漏洞。
- CVE-2023-21569:Azure DevOps Server 欺骗漏洞。
- 修复了服务连接编辑器中的 bug。 现在,组件消除时草稿终结点状态刷新。
- 修复了分离或附加集合失败并报告以下错误:“TF246018:数据库操作超出了超时限制并已取消。
Azure DevOps Server 2022 修补程序 3 发布日期:2023 年 3 月 21 日
我们发布了 Azure DevOps Server 2022 的修补程序(19.205.33506.1),其中包括以下修补程序。
- 解决了在更新 Azure DevOps Server 管理控制台中与 SMTP 相关的设置后,需要重启 tfsjobagent 服务和 Azure DevOps Server 应用程序池的问题。
- 将终结点状态复制到服务终结点编辑面板,而不是通过引用传递它。
- 以前,在编辑服务连接时,选择“取消”按钮后,编辑将保留在 UI 中。 通过此修补程序,我们已在通知 SDK 中修复了团队何时将通知传递设置为 “不传递”。 在此方案中,如果通知订阅配置了 团队首选项 传递选项,则团队成员不会收到通知。 无需进一步扩展团队下的标识以检查成员的首选项。
Azure DevOps Server 2022 修补程序 2 发布日期:2023 年 2 月 14 日
我们发布了 Azure DevOps Server 2022 的修补程序 ,其中包括以下修补程序。
- CVE-2023-21564:Azure DevOps Server 跨站点脚本漏洞
- 更新了 MSBuild 和 VSBuild 任务以支持 Visual Studio 2022。
- 更新加载重新身份验证的方法,以防止可能的 XSS 攻击途径。
- Azure DevOps Server 2022 代理报告以下错误:VS800069:此服务仅在本地 Azure DevOps 中可用。
Azure DevOps Server 2022 修补程序 1 发布日期:2023 年 1 月 24 日
我们发布了 Azure DevOps Server 2022 的修补程序 ,其中包括以下修补程序。
- 测试数据未被删除,导致数据库增长。 通过此修补程序,我们更新了生成保留期,以防止创建新的孤立测试数据。
- AnalyticCleanupJob 更新,作业状态已停止,现在我们报告“成功”。
- 修复了“tfx extension publish”命令失败,并显示“字典中不存在给定密钥”错误。
- 实现了在访问团队日历扩展时解决和错误的解决方法。
Azure DevOps Server 2022 发布日期:2022 年 12 月 6 日
Azure DevOps Server 2022 是 bug 修复的汇总。 它包括以前发布的 Azure DevOps Server 2022 RC2 和 RC1 中的所有功能。
Azure DevOps Server 2022 RC2 发布日期:2022 年 10 月 25 日
Azure DevOps Server 2022 RC2 是 bug 修复的汇总。 它包括以前发布的 Azure DevOps Server 2022 RC1 中的所有功能。
注意
已启用新的 SSH RSA 算法
除了我们以前支持的 SHA1 SSH-RSA 之外,还改进了 RSA 公钥支持,以支持 SHA2 公钥类型。
现在支持的公钥类型包括:
- SSH-RSA
- RSA-SHA2-256
- RSA-SHA2-512
需要执行操作
如果在文件中显式指定 .ssh/config1
SSH-RSA 来实现启用 SSH-RSA 的解决方法,则需要删除 PubkeyAcceptedTypes
该文件,或者将其修改为使用 RSA-SHA2-256 或 RSA-SHA2-512,或两者兼有。 如果仍提示输入密码,并在GIT_SSH_COMMAND="ssh -v" git fetch
此处的文档中没有显示相互签名算法,则可以找到有关如何执行操作的详细信息。
尚未添加椭圆键支持,并且在我们的积压工作中仍具有高度要求的功能。
Azure DevOps Server 2022 RC1 发布日期:2022 年 8 月 9 日
Azure DevOps Server 2022 中的新增功能摘要
重要
Azure DevOps Server 的早期版本(2020 年)中弃用了仓库和分析服务。 在 Azure DevOps Server 2022 中,仓库和分析服务已从产品中删除。 分析现在提供产品内报告体验。
Azure DevOps Server 2022 引入了许多新功能。 其中一些重要内容包括:
还可以跳转到各个部分,查看每个服务的所有新功能:
Boards
交付计划
我们很高兴地宣布,交付计划现已包含在 Azure DevOps Server 中。 交付计划提供 3 个关键方案:
- 计划的日程表视图
- 工作进度
- 依赖项跟踪
以下是主要功能。 筛选、标记和字段条件也是交付计划的一部分。
有两个主要视图:精简和扩展
传递计划 2.0 允许使用开始日期和目标日期或迭代日期在日程表上查看计划中的所有工作项。优先级顺序是开始日期和目标日期,然后是迭代。 这样,便可以添加项目组合级别工作项,例如通常未定义为迭代的项目组合级别工作项。
压缩视图和展开视图有两个主要视图。 还可以通过单击计划的视线边的放大镜来放大和缩小计划。
压缩视图和展开视图有两个主要视图。 还可以通过在计划的右侧单击放大镜来放大和缩小计划。
精简视图
精简视图显示所有工作项卡片 已 折叠,这意味着并非所有卡片信息都显示。 此视图对于计划中工作的总体视图非常有用。 若要折叠卡片字段,请单击计划右侧放大图标旁边的卡片图标。
下面是在精简视图和展开视图之间切换的计划的示例。
展开视图
展开的视图通过计数子项和链接项数并显示完成百分比来显示工作项的进度。 当前进度由工作项计数确定。
下面是使用扩展视图的计划示例。 记下进度条和完成百分比。
依赖项跟踪
依赖项跟踪基于工作项中定义的前置链接和后续链接。 如果未定义这些链接,则不会显示任何依赖项行。 当工作项存在依赖项问题时,依赖项链接图标的颜色为红色。
查看依赖项
通过依赖项面板查看特定依赖项,其中显示了该工作项的所有依赖项,包括方向。 红色感叹号表示依赖项问题。 若要打开面板,只需单击卡片右上角的依赖项链接图标即可。 下面是依赖项的示例。
依赖项行
工作项之间的依赖关系通过相应的工作项之间的方向箭头线进行可视化。 多个依赖项将显示为多行。 红色线条表示问题。
下面是一些示例。
下面是具有多个依赖项的工作项的示例,它也可以使用精简视图。
出现问题时,线条颜色为红色,依赖项图标也是如此。
以下是一个示例。
卡片样式
卡片现在可以使用规则(如看板)进行样式设置。 打开计划设置,然后单击“ 样式”。 在“样式”窗格中,单击“ + 添加样式规则 ”以添加规则,然后单击“ 保存”。 最多可以有 10 条规则,每个规则最多可以有 5 个子句。
- 之前
- 之后
若要了解有关交付计划的详细信息,请查看此处的文档。
工作项中心上已删除的项目
工作项中心是查看所创建或分配给你的项列表的位置。 它提供多个个性化透视和筛选函数来简化工作项列表。 “分配给我”透视的顶级投诉之一是它显示已删除的工作项。 我们同意删除的工作项不再具有价值,不应包含在积压工作中。 在此冲刺中,我们将隐藏工作项中心上“已分配给我”视图中的所有已删除项目。
在提交链接上显示正确的角色
工作项中的开发部分显示相关提交和拉取请求的列表。 可以查看提交或拉取请求的作者以及关联的时间。 通过此更新,我们修复了作者的头像在视图中显示错误的问题。
删除从工作项历史记录下载已删除附件的功能
我们修复了以下小问题:即使从表单中删除附件,用户也能从工作项历史记录下载附件。 现在,删除附件后,无法从历史记录下载附件,也无法从 REST API 响应获取下载 URL。
向 Bug 原因字段添加了“不会修复”值
与所有其他工作项类型一样,Bug 工作项类型具有定义完善的工作流。 每个工作流由三个或更多的状态和一个原因组成。 原因指定项从一个状态转换到另一个状态的原因。 通过此更新,我们添加了 “不会修复 敏捷”过程中 Bug 工作项类型的原因值。 将 Bug 从“新建”或“活动”移动到“已解决”时,该值将作为原因提供。 可以在 Azure Boards 文档中详细了解如何定义、捕获、会审和管理软件 bug。
管道
在经典版本中删除每管道保留策略
现在可以在 Azure DevOps 项目设置中为经典生成和 YAML 管道配置保留策略。 不再支持经典生成管道的按管道保留规则。 虽然这是为 YAML 管道配置保留的唯一方法,但也可以为每个管道配置经典生成管道的保留期。 我们删除了即将发布的经典生成管道的所有每管道保留规则。
这意味着什么:用于具有每管道保留规则的任何经典生成管道都将受项目级保留规则的约束。
为了确保在升级时不会丢失任何生成,我们将在升级时为所有现有生成创建租约。
建议在升级后检查项目级保留设置。 如果管道特别需要自定义规则,则可以在管道中使用自定义任务。 有关通过任务添加保留租约的信息,请参阅 生成、发布和测试文档的设置保留策略。
管道中环境变量的新控件
Azure Pipelines 代理扫描标准输出以获取特殊的 日志记录命令 并执行它们。 该setVariable
命令可用于设置变量或修改以前定义的变量。 这可能会被系统外部的参与者利用。 例如,如果管道具有打印 ftp 服务器中文件列表的步骤,则有权访问 ftp 服务器的人员可以添加新文件,其名称包含 setVariable
命令,并导致管道更改其行为。
我们有许多用户依赖于在其管道中使用日志记录命令设置变量。 在此版本中,我们将进行以下更改,以减少不需要使用该 setVariable
命令的风险。
- 我们为任务作者添加了一个新构造。 通过包括如下
task.json
代码片段,任务作者可以控制任务是否设置了任何变量。
{
"restrictions": {
"commands": {
"mode": "restricted"
},
"settableVariables": {
"allowed": [
"myVar",
"otherVar"
]
}
},
}
此外,我们正在更新许多内置任务,例如 ssh,以便无法利用它们。
最后,现在可以使用 YAML 构造来控制步骤是否可以设置变量。
steps:
- script: echo hello
target:
settableVariables: none
steps:
- script: echo hello
target:
settableVariables:
- things
- stuff
为分叉生成生成无限制令牌
GitHub Enterprise 用户通常使用分叉来参与上游存储库。 当 Azure Pipelines 从 GitHub Enterprise 存储库的分支生成贡献时,它会限制授予作业访问令牌的权限,不允许此类作业访问管道机密。 可以在我们的 文档中找到有关生成分支安全性的详细信息。
在这样的封闭环境中,这可能比所需更严格,用户仍可能受益于内部源协作模型。 虽然可以在管道中配置设置以使机密可用于分支,但没有用于控制作业访问令牌范围的设置。 通过此版本,我们让你能够控制生成常规作业访问令牌,即使生成分支也是如此。
可以在管道编辑器中从 触发器 更改此设置。 在更改此设置之前,请确保完全了解启用此配置的安全影响。
存储库作为 YAML 管道中的受保护资源
可以组织 Azure DevOps 项目来托管许多子项目 - 每个项目都有自己的 Azure DevOps Git 存储库和一个或多个管道。 在此结构中,你可能想要控制哪些管道可以访问哪些存储库。 例如,假设在同一项目中有两个存储库 A 和 B,以及通常生成这些存储库的两个管道 X 和 Y。 你可能想要阻止管道 Y 访问存储库 A。一般情况下,你希望 A 的参与者控制他们想要提供访问权限的管道。
虽然 Azure Git 存储库和管道部分可能这样做,但管理它没有经验。 此功能解决了这种差距。 Azure Git 存储库现在可以被视为 YAML 管道中的受保护资源 ,就像服务连接和代理池一样。
作为存储库 A 的参与者,可以将检查和管道权限添加到存储库。 为此,请导航到项目设置,选择“存储库”,然后选择存储库。 你会注意到一个名为“检查”的新菜单,可在其中以 Azure 函数的形式配置任何内置或自定义检查。
在“安全”选项卡下,可以管理可访问存储库的管道列表。
每当 YAML 管道使用存储库时,Azure Pipelines 基础结构都会验证并确保满足所有检查和权限。
注意
这些权限和检查仅适用于 YAML 管道。 经典管道无法识别这些新功能。
对变量组和安全文件的权限和检查
可以在 YAML 管道中使用不同类型的 共享资源 。 示例包括服务连接、变量组、安全文件、代理池、环境或存储库。 为了保护管道访问资源,资源所有者可以配置权限并检查该资源。 每次管道尝试访问资源时,都会评估所有配置的权限和检查。 这些保护已在服务连接、环境和代理池上提供一段时间。 它们最近已添加到 存储库。 在此版本中,我们将向变量组和安全文件添加相同的保护。
若要将对变量组或安全文件的访问权限限制为一小部分管道,请使用 Pipelines 权限 功能。
若要配置每次运行管道时应评估的检查或审批,请使用 审批并检查库 功能。
自动创建环境的更改
创作 YAML 管道并引用不存在的环境时,Azure Pipelines 会自动创建环境。 这种自动创建可以在用户上下文或系统上下文中进行。 在以中,Azure Pipelines 知道执行操作的用户:
- 在 Azure Pipelines Web 体验中使用 YAML 管道创建向导,并引用尚未创建的环境。
- 使用 Azure Pipelines Web 编辑器更新 YAML 文件,并在添加对不存在的环境的引用后保存管道。 在上述每种情况下,Azure Pipelines 都清楚地了解了执行操作的用户。 因此,它会创建环境,并将用户添加到环境的管理员角色。 此用户具有管理环境和/或将其他用户包含在管理环境的各种角色中的所有权限。
在以中,Azure Pipelines 没有有关用户创建环境的信息:使用另一个外部代码编辑器更新 YAML 文件,添加对不存在的环境的引用,然后触发持续集成管道。 在这种情况下,Azure Pipelines 并不了解用户。 以前,我们通过将所有项目参与者添加到环境的管理员角色来处理这种情况。 然后,项目的任何成员都可以更改这些权限,并阻止其他人访问环境。
我们收到了有关向项目的所有成员授予环境管理员权限的反馈。 当我们听取你的反馈时,我们听说,如果对执行操作的用户不清楚,则不应自动创建环境。 在此版本中,我们对环境自动创建方式进行了更改:
- 今后,管道运行不会在环境不存在且用户上下文未知的情况下自动创建环境。 在这种情况下,管道将失败,并 出现“未找到环境”错误。 在管道中使用环境之前,需要预先创建具有适当安全性的环境并检查配置。
- 具有已知用户上下文的管道仍将像过去那样自动创建环境。
- 最后,应注意,仅添加了自动创建环境的功能,以简化 Azure Pipelines 入门过程。 它适用于测试方案,不适用于生产方案。 应始终预先创建具有适当权限和检查的生产环境,然后在管道中使用它们。
从生成管道中删除见解对话
根据你的反馈,任务/管道见解对话框在导航生成管道时显示,以改进工作流。 管道分析仍可用,以便获得所需的见解。
仅当使用排他锁检查时,才支持顺序部署,而不是最新部署
在 YAML 管道中,检查用于控制受保护资源上的阶段的执行。 可以使用的一项 常见检查是独占锁检查。 此检查仅允许从管道运行单个运行。 当多个运行尝试同时部署到环境时,检查将取消所有旧运行并允许部署最新的运行。
如果发布是累积的,并且包含以前运行的所有代码更改,则取消旧运行是一个很好的方法。 但是,某些管道中的代码更改不是累积的。 通过这项新功能,可以选择允许所有运行继续并按顺序部署到环境,或保留取消旧运行并仅允许最新运行以前的行为。 可以使用管道 YAML 文件中调用 lockBehavior
的新属性指定此行为。 sequential
这意味着所有运行都按顺序获取受保护资源的锁。 runLatest
这意味着只有最新运行获取资源锁的值。
要将排他锁检查用于 sequential
部署或 runLatest
,请执行以下步骤:
- 在环境(或其他受保护资源)上启用排他锁检查。
- 在管道的 YAML 文件中,指定名为
lockBehavior
的新属性。 可以针对整个管道或给定的阶段指定此属性:
在阶段上设置:
stages:
- stage: A
lockBehavior: sequential
jobs:
- job: Job
steps:
- script: Hey!
在管道上设置:
lockBehavior: runLatest
stages:
- stage: A
jobs:
- job: Job
steps:
- script: Hey!
如果未指定, lockBehavior
则假定为 runLatest
。
支持魁北克版本的 ServiceNow
Azure Pipelines 与 ServiceNow 的现有集成。 集成依赖于 ServiceNow 中的应用和 Azure DevOps 中的扩展。 我们现在更新了应用,以使用魁北克版本的 ServiceNow。 经典管道和 YAML 管道现在都与魁北克合作。 若要确保此集成有效,请从 Service Now 商店升级到新版本的应用(4.188.0)。 有关详细信息,请参阅 与 ServiceNow 更改管理集成。
新的 YAML 条件表达式
在 YAML 文件中编写条件表达式更容易使用 ${{ else }}
和 ${{ elseif }}
表达式。 下面是如何在 YAML 管道文件中使用这些表达式的示例。
steps:
- script: tool
env:
${{ if parameters.debug }}:
TOOL_DEBUG: true
TOOL_DEBUG_DIR: _dbg
${{ else }}:
TOOL_DEBUG: false
TOOL_DEBUG_DIR: _dbg
variables:
${{ if eq(parameters.os, 'win') }}:
testsFolder: windows
${{ elseif eq(parameters.os, 'linux' }}:
testsFolder: linux
${{ else }}:
testsFolder: mac
支持路径筛选器中的通配符
指定管道 YAML 文件中 CI 或 PR 触发器的包含和排除分支时,可以使用通配符 。 但是,指定路径筛选器时无法使用它们。 例如,不能包含匹配 src/app/**/myapp*
的所有路径。 这一点被指出为几个客户带来的不便。 此更新填补了此空白。 现在,可以在指定路径筛选器时使用通配符(**
或*
?
)。
管道的默认代理规范将是 Windows-2022
映像 windows-2022
已准备好成为 Azure Pipelines Microsoft 托管代理中标签的默认版本 windows-latest
。 到目前为止,此标签指向 windows-2019 代理。 从1月17日开始的几周内,此更改将推出。 我们计划在 3 月前完成迁移。
Azure Pipelines 自 2021 年 9 月以来一直受 windows-2022
支持。 我们已监视你的反馈,以提高 windows-2022
图像稳定性,现在我们已准备好将其设置为最新。
该 windows-2022
映像包括 Visual Studio 2022。 有关差异 windows-2022
的完整列表, windows-2019
请访问 GitHub 问题。 有关映像上安装的软件的完整列表,请查看 此处。
管道文件夹重命名验证权限
可以重命名包含管道的文件夹。 仅当用户对文件夹中至少包含的一个管道具有编辑权限时,重命名文件夹才会成功。
Pipelines 代理运行时升级规划
什么是管道代理?
Azure DevOps Pipeline Agent 是在管道主机上运行以执行管道作业的软件产品。 它在Microsoft托管代理、规模集代理和自承载代理上运行。 在后一种情况下,你自行安装它。 管道代理由侦听器和辅助角色(在 .NET 中实现)组成,辅助角色运行在 Node 或 PowerShell 中实现的任务,因此为它们托管这些运行时。
即将升级到 .NET 6 和 Red Hat 6 弃用
随着 .NET 6 的发布,我们能够利用其新的跨平台功能。 具体而言,我们将能够为 Apple Silicon 和 Windows Arm64 提供本机兼容性。 因此,我们计划在未来几个月内迁移到管道代理(侦听器和辅助角色)的 .NET 6。
由于存在许多限制,我们将从 2022 年 4 月 30 日代理中删除 Red Hat Enterprise Linux 6 支持。
Azure 文件复制任务的更新
我们正在推出新版本的 Azure 文件复制任务。 此任务用于将文件复制到Microsoft Azure 存储 blob 或虚拟机(VM)。 新版本包含社区经常请求的多个更新:
AzCopy 工具的版本已更新为 10.12.2,它支持文件内容类型。 因此,复制 PDF、Excel、PPT 或其中一种受支持的 mime 类型时,文件内容类型已正确设置。
使用新版本的 AzCopy,还可以配置一个设置,以在目标类型为 Azure Blob 时清理目标。 设置此选项将删除该容器中的所有文件夹/文件。 或者,如果提供了 blob 前缀,则会删除该前缀中的所有文件夹/文件。
新版本的任务依赖于在代理上安装的 Az 模块,而不是 AzureRM 模块。 在某些情况下,使用任务时,这将删除不必要的警告。
这些更改是此任务的主要版本更新的一部分。 必须显式更新管道才能使用新版本。 我们选择了更新主版本,以确保不会中断仍依赖于 AzureRM 模块的任何管道。
管道详细信息视图的新扩展点
我们添加了可在扩展中面向的两个新的扩展点。 通过这些扩展点,可以在管道标头中添加自定义按钮,并在管道文件夹上添加自定义菜单:
- 管道标头中的“自定义”按钮:
ms.vss-build-web.pipelines-header-menu
- 管道文件夹上的自定义菜单:
ms.vss-build-web.pipelines-folder-menu
若要使用这些新的扩展点,只需在 Azure DevOps 扩展的vss-extension.json
清单文件中添加新贡献即可。
例如:
"contributions": [
{
"id": "pipelinesFolderContextMenuTestItem",
"type": "ms.vss-web.action",
"description": "Custom menu on a pipeline folder",
"targets": [
"ms.vss-build-web.pipelines-folder-menu"
],
"properties": {
"text": "Test item",
"title": "ms.vss-code-web.source-item-menu",
"icon": "images/show-properties.png",
"group": "actions",
"uri": "main.html",
"registeredObjectId": "showProperties"
}
},
{
"id": "pipelinesHeaderTestButton",
"type": "ms.vss-web.action",
"description": "Custom button in the pipeline header",
"targets": [
"ms.vss-build-web.pipelines-header-menu"
],
"properties": {
"text": "Test item",
"title": "ms.vss-code-web.source-item-menu",
"icon": "images/show-properties.png",
"group": "actions",
"uri": "main.html",
"registeredObjectId": "showProperties"
}
}
]
结果为:
管道标头中的“自定义”按钮
管道文件夹上的自定义菜单
改进了迁移到 Azure DevOps Services
从 Azure DevOps Server 运行从 Azure DevOps Server 导入到 Azure DevOps Services 时,必须考虑 Azure DevOps 不再支持每管道保留规则。 通过此更新,从本地 Azure DevOps Server 迁移到 Azure DevOps Services 时,我们删除了这些策略。 若要详细了解如何配置保留策略,请参阅有关 设置生成、发布和测试保留策略的文档。
对管道运行的 REST API 的改进
以前, 管道运行 REST API 仅 self
返回存储库。 通过此更新,管道运行 REST API 将返回生成的所有存储库资源。
现在可以为阶段、作业和部署传递扩展 YAML 管道模板的上下文信息
通过此更新,我们将为和 YAML 管道组件添加新templateContext
属性deployment
job
stage
,这些组件旨在与模板结合使用。
下面是使用 templateContext
以下方案:
使用模板减少代码重复或 提高管道的安全性
模板采用参数
stages
列表,jobs
或deployments
模板处理输入列表,并在每个阶段、作业或部署上执行一些转换。 例如,它设置每个作业运行或添加其他步骤以强制实施符合性的环境
处理需要管道作者将其他信息传递到列表中的每个阶段、作业或部署的模板中
我们来看一个示例。 假设你正在创作一个管道,该管道运行端到端测试以拉取请求验证。 你的目标是仅测试系统的一个组件,但是,由于你计划运行端到端测试,因此需要一个环境,其中更多的系统组件可用,你需要指定其行为。
你意识到其他团队将有类似的需求,因此你决定将环境设置的步骤提取到模板中。 其代码如下所示:
testing-template.yml
parameters:
- name: testSet
type: jobList
jobs:
- ${{ each testJob in parameters.testSet }}:
- ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 200) }}:
- job:
steps:
- script: ./createSuccessfulEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
- ${{ testJob.steps }}
- ${{ if eq(testJob.templateContext.expectedHTTPResponseCode, 500) }}:
- job:
steps:
- script: ./createRuntimeErrorEnvironment.sh ${{ testJob.templateContext.requiredComponents }}
- ${{ testJob.steps }}
模板的作用是,对于参数中的每个 testSet
作业,它设置由 ${{ testJob.templateContext.requiredComponents }} 指定的系统的组件的响应,以返回 ${{ testJob.templateContext.expectedHTTPResponseCode }}。
然后,可以创建自己的管道,如 testing-template.yml
以下示例所示。
sizeapi.pr_validation.yml
trigger: none
pool:
vmImage: ubuntu-latest
extends:
template: testing-template.yml
parameters:
testSet:
- job: positive_test
templateContext:
expectedHTTPResponseCode: 200
requiredComponents: dimensionsapi
steps:
- script: ./runPositiveTest.sh
- job: negative_test
templateContext:
expectedHTTPResponseCode: 500
requiredComponents: dimensionsapi
steps:
- script: ./runNegativeTest.sh
此管道运行两个测试,一个是正测试,一个是负测试。 这两个 dimensionsapi
测试都需要组件可用。 作业 positive_test
需要 dimensionsapi
返回 HTTP 代码 200,而 negative_test
预期返回 HTTP 代码 500。
支持组托管服务帐户作为代理服务帐户
Azure Pipelines 代理现在支持 Windows 上自承载代理上的组托管服务帐户。
组托管服务帐户 为充当服务帐户的域帐户提供集中式密码管理。 Azure Pipelines 代理可以识别这种类型的帐户,因此在配置过程中不需要密码:
.\config.cmd --url https://dev.azure.com/<Organization> `
--auth pat --token <PAT> `
--pool <AgentPool> `
--agent <AgentName> --replace `
--runAsService `
--windowsLogonAccount <DOMAIN>\<gMSA>
信息性运行
信息性运行告知 Azure DevOps 无法检索 YAML 管道的源代码。 此类运行如下所示。
例如,Azure DevOps 检索 YAML 管道的源代码,以响应外部事件,例如,推送提交或响应内部触发器,例如,检查是否存在代码更改并启动计划的运行。 此步骤失败时,系统将创建一个信息性运行。 仅当管道的代码位于 GitHub 或 BitBucket 存储库中时,才会创建这些运行。
检索管道的 YAML 代码可能由于以下原因而失败:
- 存储库提供程序遭遇中断
- 请求限制
- 身份验证问题
- 无法检索管道.yml文件的内容
详细了解 信息运行。
生成定义 REST API retentionRules
属性已过时
在 生成定义 REST API 的 BuildDefinition
响应类型中,该 retentionRules
属性现在标记为已过时,因为此属性始终返回空集。
Repos
新建 TFVC 页面
我们一直在更新 Azure DevOps 中的各种页面,以使用新的 Web 平台,目的是使体验在各种服务中更加一致且更易于访问。 TFVC 页面已更新为使用新的 Web 平台。 使用此版本,我们将推出新的 TFVC 页面。
禁用存储库
客户经常请求一种方法来禁用存储库,并阻止用户访问其内容。 例如,你可能希望在以下情况下执行此操作:
- 在存储库中找到了机密。
- 第三方扫描工具发现存储库不符合要求。
在这种情况下,你可能希望在解决问题时暂时禁用存储库。 使用此更新,如果具有 “删除存储库”权限,则可以禁用存储库 。 通过禁用存储库,可以:
- 可以在存储库列表中列出存储库
- 无法读取存储库的内容
- 无法更新存储库的内容
- 查看在 Azure Repos UI 中尝试访问存储库时已禁用存储库的消息
执行必要的缓解步骤后,具有 “删除存储库 ”权限的用户可以重新启用存储库。 若要禁用或启用存储库,请转到“项目设置”,选择“存储库”,然后选择特定的存储库。
配置了分支创建者,使其不会在其分支上获得“管理权限”
创建新分支时,在该分支上获得“管理权限”。 此权限允许你更改其他用户的权限,或允许其他用户参与该分支。 例如,分支创建者可以使用此权限允许另一个外部用户更改代码。 或者,它们可能允许管道(生成服务标识)更改该分支中的代码。 在某些符合性要求较高的项目中,用户不应进行此类更改。
通过此更新,可以配置团队项目中的任何存储库和所有存储库,并限制分支创建者获取“管理权限”权限。 为此,请导航到项目设置,选择存储库,然后为所有存储库或特定存储库设置。
此设置默认处于打开状态,用于模拟现有行为。 但是,如果想要使用此新的安全功能,可以将其关闭。
阻止分叉用户对其上游拉取请求投票
使用 Azure Repos 时,对存储库具有“读取”权限的用户可以分支存储库并对其分支进行更改。 若要将拉取请求及其更改提交到上游,用户需要对上游具有“参与拉取请求”权限。 但是,此权限还控制谁可以在上游存储库中投票拉取请求。 因此,最终,在用户不是存储库参与者的情况下,可以提交拉取请求并导致合并,具体取决于如何设置分支策略。
在提升内部源模型的项目中,分叉和参与是一种常见模式。 为了进一步保护和促进这种模式,我们将更改对拉取请求进行投票的权限,从“参与拉取请求”更改为“参与”。 但是,默认情况下不会在所有项目中进行此更改。 必须选择加入并在存储库中选择一个新策略,称为“严格投票模式”才能切换此权限。 如果依赖于 Azure Repos 中的分支,我们建议这样做。
正在报告
图表小组件中可用的分组依据标记
“按标记分组”图表小组件现在默认适用于所有客户。 使用图表小组件时,现在有一个选项可用于标记。 用户可以通过在小组件中选择所有标记或一组标记来可视化其信息。
在“烧毁”小组件中显示自定义工作项类型
以前,你看不到在“烧毁”小组件中配置的自定义工作项类型,并且自定义字段已求和或计数。 在此更新中,我们修复了此问题,现在你可以在“正在烧毁”小组件中看到自定义工作项类型。
反馈
我们期待你的宝贵意见和建议! 你可以报告问题或提供想法并通过开发者社区跟踪它,并获取有关 Stack Overflow 的建议。