通过

基于用户分配的计费、默认访问级别和每日计费 - Sprint 158 更新

  • 项目

在 Azure DevOps 的 Sprint 158 更新 中，我们添加了基于用户分配的计费。 使用此功能后，基本或基本 + 测试计划许可证的数量将随着添加或删除用户而更改。 这意味着，你只需为所使用的许可证付费。 我们还添加了一个新设置，允许你选择是希望将新用户添加到组织以获取完全基本访问权限还是受限/免费利益干系人访问权限。

此外，我们还将每月计费改为每日计费。 这意味着，如果你为用户分配了几周甚至几天的付费访问权限，则只需为他们分配到付费访问权限的时间付费，而无需付整月的费用。

有关详细信息， 请查看下面的功能 列表。

Azure DevOps 中的新增功能

功能

常规：

Azure Boards：

Azure Repos：

Azure Pipelines：

Azure Test Plans：

报表：

Wiki：

常规

基于用户分配的计费和默认访问级别

基于用户分配的计费

通过此更新，我们添加了基于用户分配的计费。 现在，添加或删除用户或更改其访问级别时，组织可以使用的付费基本或基本 + 测试计划许可证数量，而无需增加或减少其分配的付费 基本 或 基本 + 测试计划 许可证的数量。 这意味着你永远不会支付比使用的许可证更多的费用，并使访问级别分配自动化要容易得多。 例如，你已经能够设置组规则来控制将哪些访问级别分配给自动加入团队的新用户。 但是，过去，只有在你支付的额外许可证尚未分配给任何人的情况下，这些许可证才起作用，如果你用完了，组 规则 会失败。 只要用于计费的 Azure 订阅保持活动状态，这些错误类型就不再发生。

新用户的默认访问级别

我们还添加了一个新设置，允许你选择是希望将新用户添加到组织以获取完全基本访问权限还是受限/免费利益干系人访问权限。 过去，如果有未分配的基本许可证可用，则新用户获得 Basic，但如果没有，则获得利益干系人。 所有组织都将从其默认访问级别设置为“利益干系人”开始，因此新用户不会产生任何意外费用。 如果组织通常保留额外的未分配许可证，因此添加到项目的新用户具有完全的基本访问权限，请确保将 默认访问级别更改为“基本”。

Default access level for new users.

每日计费

作为基于分配的计费更改的一部分，我们还从每月计费切换到每日计费。 现在，如果你为用户提供数周甚至几天的付费访问权限，则只需为他们分配付费访问权限的时间付费，而不是一整个月。 当我们将组织从每月计费切换到每日计费时，下一个 Azure 帐单可能低于以前。 下个月将恢复正常，一旦有一整个月的累计每日费用。

用于管理组织和项目权限的新 UI

组织和项目权限管理有了新的外观和性能改进。 现在，新组成员将出现在列表中，因为它们是添加的，无需强制页面刷新。 前往组织设置并查看。

Manage organization and project permissions.

Azure Boards

支持汇总列中的自定义字段

现在可以对任何字段（包括自定义字段）执行汇总操作。 添加汇总列时，仍然可以从“快速”列表中选取一个汇总列，但是，如果要对不属于现成流程模板的数字字段进行汇总，则可以按以下方式配置自己的字段：

  1. 在积压工作 (backlog) 上单击“列选项”。 然后在面板中单击“添加汇总列”并 配置自定义汇总。

    Rollup on custom fields.

  2. 在进度栏和总计之间进行选取。
  3. 选择一个工作项类型或积压工作 (backlog) 级别（通常积压工作会聚合多个工作项类型）。
  4. 选择聚合类型。 工作项 或 总和的计数。 对于总和，需要选择要汇总的字段。
  5. “ 确定 ”按钮将返回到列选项面板，可在其中重新排序新的自定义列。

Support for custom fields in Rollup columns.

请注意，单击“确定”后无法编辑自定义列。 如果需要进行更改，请删除自定义列，然后根据需要添加另一列。

用于根据条件隐藏工作项窗体中的字段的新规则

我们在继承的规则引擎中添加了新规则，以便你可以隐藏工作项窗体中的字段。 此规则将基于用户组成员身份隐藏字段。 例如，如果用户属于“产品所有者”组，则可以隐藏开发者特定的字段。 有关更多详细信息，请参阅此处的文档。

自定义工作项通知设置

掌握与你或你的团队相关的工作项的最新动态非常重要。 这有助于团队协作，保持项目的正常运行，并确保所有相关方都参与进来。 但是，不同的利益干系人在不同的工作上有不同的投资水平，我们认为这应该反映在你跟踪工作项状态的能力上。

以前，如果你想要跟踪工作项并获取有关所做任何更改的通知，你将收到关于对工作项所做的所有更改的电子邮件通知。 在考虑了你的反馈后，我们正在为所有利益干系人提供跟踪工作项更灵活的方式。 现在，你将在工作项右上角的 “关注 ”按钮旁边看到一个新的设置按钮。 按下该按钮，将出现一个弹出窗口，你可以在其中配置以下选项。

Configure follow options.

从通知设置，可以从三个通知选项中进行选择。 首先，你可以选择完全取消订阅。 其次，你可以选择完全订阅，从而获取有关所有工作项更改的通知。 最后，你可以选择接收一些有关最重要的工作项更改事件的通知。 可以只选择一个选项，也可以选择所有三个选项。 这样，团队成员可以在更高的级别跟踪工作项，而不会因每一个更改而分心。 利用此功能，我们可以避免不必要的电子邮件，使你专注于当前的重要任务。

Choose Notification Settings.

我们很高兴在工作项窗体上发布部署控件预览版。 此控制将工作项链接到一个版本，并使你能够轻松跟踪工作项的部署位置。 若要了解详细信息，请参阅此处的文档。

Link work items to deployments.

Azure Repos

使用基于服务帐户的身份验证连接到 AKS

以前，从 AKS 部署中心配置 Azure Pipelines 时，我们使用 Azure 资源管理器连接。 此连接可以访问整个群集，而不只是配置了管道的命名空间。 通过此更新，我们的管道将使用基于服务帐户的身份验证来连接到群集，使它将只能访问与管道关联的命名空间。

在拉取请求并行差异中预览 Markdown 文件

现在，可以使用新的 预览 按钮查看 Markdown 文件的外观预览。 此外，还可以通过选择 “视图 ”按钮，从并排差异查看文件的完整内容。

Preview Markdown files in pull request Side-by-side diff.

手动生成的生成策略有效期

这些策略强制实施团队的代码质量和更改管理标准。 以前，你可以为自动生成设置生成到期策略。 现在你也可以为手动生成设置生成到期策略。

Build policy expiration for manual builds.

添加策略以阻止基于提交作者电子邮件的提交

管理员现在可以设置推送策略，以防止将提交推送到提交作者的电子邮件与提供的模式不匹配的存储库。

Add a policy to block commits based on the commit author email.

此功能基于来自开发者社区的建议设置优先级，以提供类似的体验。 我们将继续保持工单的打开状态，并鼓励用户告知想要查看的其他类型的推送策略。

Azure Pipelines

重试失败阶段

注意

若要试用此功能，必须启用预览功能 多阶段管道 。

在多阶段管道中，最需要的功能之一是无需从头开始就可以重试失败的阶段。 在此次更新中，我们添加了此功能的一个重要部分。

现在可以在执行失败时重试管道阶段。 系统将重新尝试在第一次尝试中失败的任何作业以及那些间接依赖于这些失败作业的作业。

这可以通过多种方式帮助你节省时间。 例如，在一个阶段中运行多个作业时，你可能会希望每个阶段在不同的平台上运行测试。 如果一个平台上的测试失败，而其他平台通过，那么可以不用重新运行通过的作业，从而节省时间。 另一个例子是，部署阶段可能由于不可靠的网络连接而失败。 可通过重试该阶段来节省时间，因为无需生成另一个生成。

此功能存在一些已知的差距。 例如，无法重试已明确取消的阶段。 我们正在努力在将来的更新中弥补这些缺陷。

YAML 管道中审批的增强功能

注意

必须启用 多阶段管道 和新 服务连接体验 预览功能才能试用此功能。

我们将继续改进多阶段 YAML 管道。 通过此更新，我们启用了在服务连接和代理池上配置审批。 对于审批，我们遵循基础结构所有者和开发人员之间的角色分割。 通过配置资源（例如环境、服务连接和代理池）审批，可确保所有使用资源的管道运行都需要先获得审批。

这种经验类似于为环境配置审批。 当对某个阶段中引用的资源的审批处于挂起状态时，执行的管道将等待，直到手动批准管道为止。

Enhancements to approvals in YAML pipelines.

Azure Pipelines 中的容器结构测试支持

应用程序中容器的使用正在增加，因此需要可靠的测试和验证。 Azure Pipelines 现在支持 容器结构测试。 此框架提供了一种方便而强大的方法来验证容器的内容和结构。

可以根据可同时运行的四类测试来验证映像的结构：命令测试、文件存在测试、文件内容测试和元数据测试。 你可以基于管道中的结果来决定是否执行。 可在管道运行中使用测试数据，并显示错误消息，以帮助你更好地排除故障。

输入配置文件和映像详细信息

Container structure testing support in Azure Pipeline.

测试数据和摘要

Test data and summary.

不可靠的 bug 管理和解决方案

今年7月，我们引入了不起的测试管理，以支持具有检测、报告和解决的端到端生命周期。 为了进一步增强该功能，我们添加了不可靠的测试 bug 管理和解决方案。

在调查浮点测试时，可以使用 Bug 操作创建 bug，然后可以分配给开发人员进一步调查异常测试的根本原因。 Bug 报告包括有关管道（例如错误消息）、堆栈跟踪的信息，以及与测试相关的其他信息。

解决或关闭 Bug 报告后，我们会自动将测试标记为不可靠。

对适用于 Slack 和 Microsoft Teams 的 Azure Pipelines 应用的增强

基于 YAML 的多阶段管道

注意

若要试用此功能，必须启用预览功能 多阶段管道 。

适用于 Slack 和 Microsoft Teams 的 Azure Pipelines 应用现在支持 CI 和 CD 的多阶段 YAML 管道。 通过此增强功能，你将收到与 YAML 管道相关的各种事件的通知。

Enhancements to Azure Pipelines app for Slack and Microsoft Teams.

多阶段 YAML 管道支持的事件

  • 运行状态已更改
  • 运行阶段状态已更改
  • 等待审批的运行阶段
  • 运行阶段审批已完成

Events supported for multi-stage YAML pipelines.

URL 展开和消息传递扩展

我们添加了 适用于 Microsoft Teams 的 Azure Pipelines 应用的消息传递扩展 。 现在可以搜索管道，并将有关管道的相关详细信息共享为通道中的卡。 URL 展开有助于启动有关管道的讨论，并具有有意义的上下文对话。

URL unfurling and messaging extensions.

托管管道映像的更新

我们更新了多个 Azure Pipelines 托管的 VM 映像。 以下是此更新中的一些亮点：

  • 向 Ubuntu 16.04、Ubuntu 18.04、VS2017 和 VS2019 添加了 Go 1.13。 Go 1.12 仍然是默认值。
  • 向 Ubuntu 16.04、Ubuntu 18.04、VS2017 和 VS2019 添加了 Android SDK 和生成工具 29。
  • 向 VS2017 和 VS2019 添加了 Az Module 2.6.0。
  • 修复了多个 Bug。

可在此处找到有关最新版本的更多详细信息。

注意

自 2019 年 3 月 31 日结束映像以来，我们将从所有映像中删除 Ruby 2.3。

Open Policy Agent 安装程序任务

Open Policy Agent 是一个开放源代码的通用策略引擎，可实现统一的上下文感知策略强制实施。 我们添加了 Open Policy Agent 安装程序任务。 对于基础结构即代码提供程序的管道内策略强制实施，这特别有用。

例如，Open Policy Agent 可以评估管道中的 Rego 策略文件和 Terraform 计划。

task: OpenPolicyAgentInstaller@0
    inputs:
          opaVersion: '0.13.5'

发布管道的管道修饰器

可使用管道修饰器向每个作业的开头和结尾添加步骤。 这不同于将步骤添加到单个定义，因为它适用于组织中的所有管道。

我们一直支持用于生成和 YAML 管道的修饰器，客户可使用它们来集中控制其作业中的步骤。 现在，我们将该支持扩展到了发布管道。 你可以创建扩展来添加面向新贡献点的步骤，并将其添加到发布管道中的所有代理作业中。

Azure Test Plans

新 Test Plans 页面

现在，新的“测试计划”页中提供了大多数规划、创作、执行和跟踪功能。 因此，我们正在为所有测试计划用户启用它，以便他们可以向我们提供反馈。 接下来的几个冲刺中将启用剩余的几个功能，以便我们达到与之前的测试计划页面的奇偶一致。 如有必要，用户可以在“预览功能”菜单上禁用“测试计划”页。 在此处了解详细信息。

正在报告

使用故事点的内联冲刺 (sprint) 燃尽

冲刺 (sprint) 燃尽现在可以按情景燃尽。 这解决了来自开发者社区的反馈。

从冲刺中心选择“分析”选项卡。然后按如下所示配置报表：

  1. 选择情景积压工作 (backlog)
  2. 选择以烧毁 故事点的总和

Inline sprint burndown using story points.

Wiki

简短易懂的 Wiki 页面 URL

你不再需要使用多行 URL 来共享 Wiki 页面链接。 我们将利用 URL 中的页面 ID 来删除参数，从而使 URL 更短且更容易理解。

URL 的新结构如下所示：

https://dev.azure.com/{accountName}/{projectName}/_wiki/wikis/{wikiName}/{pageId}/{readableWiki PageName}

这是欢迎使用 Azure DevOps Wiki 页的新 URL 示例：

https://dev.azure.com/microsoft/ AzureDevOps/_wiki/wikis/AzureDevOps.wiki/1/Welcome-to-Azure-DevOps-Wiki

它根据来自开发者社区的功能建议工单确定优先级。

Wiki 中的 Mermaid 关系图支持

我们添加了在 Wiki 页面中插入 美人鱼图 的支持。 现在可以在 Azure DevOps Wiki 的规划文档中创建、编辑和管理流程图、对设计文档中的图表进行排序，并在规划文档中添加甘特图。

Mermaid diagram support in wiki.

它根据来自开发者社区的功能建议工单确定优先级。 有关美人鱼图的详细信息，请参阅此处的文档。

后续步骤

注意

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

前往 Azure DevOps 并了解一下。

转到 Azure DevOps

如何提供反馈

我们很想听听你对这些功能的看法。 使用反馈菜单报告问题或提供建议。

Make a suggestion

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

此致

拉维·尚克