适用于 Slack 的新分析报告和 Azure Boards 应用 - Sprint 155 更新

  • 项目

在 Azure DevOps 的冲刺 (Sprint) 155 更新中，我们将推出新的 Azure Boards 报表，让你能够更轻松地跟踪重要团队指标。 可在 Boards、积压工作 (Backlog) 和冲刺 (Sprint) 中心的“Analytics”选项卡下看到新报表。 这些报表具有很强的交互性，你可以对其进行调节以满足自己的需求。

此外，我们还很高兴地宣布推出新的面向 Slack 的 Azure Boards 应用。 通过该应用，可从 Slack 通道监视工作项活动、创建工作项。

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

Azure DevOps 中的新增功能

功能

常规：

Azure Boards：

Azure Repos：

Azure Artifacts：

Azure Pipelines：

   多阶段 YAML 管道

托管 VM

Kubernetes

测试

Azure 体验

集成

常规

邀请 GitHub 协作者加入 Azure DevOps

现在，使用 GitHub 标识登录时，可以将协作者从 GitHub 邀请到 Azure DevOps。 可以从 Project 主页和组织设置中的“用户”页面搜索和邀请其他 GitHub 用户。

Invite GitHub collaborators into Azure DevOps.

必须通过“组织”设置中的“策略”下的设置为现有组织启用此功能。 但是，默认情况下，对于由 GitHub 标识创建的组织，它处于打开状态。

Enable for existing organizations.

注意

此功能不适用于非 GitHub 用户，即使策略已启用也是如此。

若要了解有关邀请团队成员的详细信息，请参阅此处的文档。 如果在使用 GitHub 连接到 Azure DevOps 时遇到问题，请参阅 故障排除身份验证和邀请 GitHub 用户常见问题解答。

Azure Boards

通过三份新的 Azure Boards 报表深入了解你的团队的运行状况

无法修复不能查看的内容。 因此，需要密切关注其工作流程的状态和运行状况。 通过这些报告，你可以更轻松地在 Azure Boards 中花最少的精力跟踪重要指标。

这三个新的交互式报告包括： “烧毁”、“ 累积流图 ”和 “速度”。 可以在新的分析选项卡中查看报表。

冲刺 (sprint) 燃尽 (burndown)、工作流程和团队速度等指标可以让你了解团队的进度，并帮助你回答以下问题：

  • 此冲刺 (sprint) 中剩余多少工作量？ 我们是否按照正常进度完成该工作？
  • 开发过程中哪一步花费的时间最长？ 我们能做些什么呢？
  • 根据之前的迭代，我们应该为下一个冲刺 (sprint) 计划多少工作量？

注意

之前在标头中显示的图表已替换为这些增强的报表。

新的报表是完全交互式的，允许你根据需要进行调整。 可以在每个中心的“分析”选项卡下找到新报表。

  • 可以在冲刺中心下找到烧毁图表。

    Analytics tab in Sprint hub.

  • 可以通过单击相关卡，从“开发板”和“积压工作”下的“分析”选项卡访问CFD和速度报告。

    CFD and velocity reports in boards.

使用新的报表，你可以更好地控制团队并了解有关团队的信息。 以下是一些示例：

  • 冲刺 (sprint) 燃尽 (burndown) 和速度报告可设置为使用工作项计数或剩余工作量总和。
  • 可以在不影响项目日期的情况下调整冲刺 (sprint) 燃尽 (burndown) 的时间范围。 因此，如果你的团队通常在每个冲刺 (sprint) 的第一天制定计划，那么你现在可以匹配图表来反映这一点。
  • 燃尽图现在带有显示周末的水印。
  • 通过CFD报表，可以删除设计等板列，以便更专注于团队所控制流。

下面是 CFD 报表的一个示例，其中显示了情景积压工作 (backlog) 最近 30 天的流。

Example of the CFD report.

现在可以跟踪所有积压工作 (backlog) 级别的速度图表。 例如，现在可以同时添加功能和长篇故事，而之前的图表只支持需求。 下面是功能积压工作 (backlog) 的最后 6 次迭代的速度报告示例。

Example of a velocity report.

适用于 Slack 的 Azure Boards 应用

我们很高兴宣布适用于 Slack 的新 Azure Boards 应用。 使用此应用，你可以监视工作项活动，并从 Slack 通道创建工作项。

应用允许你设置和管理事件订阅，包括创建和工作项更新，以及获取 Slack 通道中这些事件的通知。 Slack 通道中的对话可用于创建工作项。 分配工作项时，你还将收到个人通知。 此外，工作项 URL 的预览版可让你开始讨论。

Azure Boards app for Slack.

若要安装 Azure Boards 应用，请 单击此处。

自定义任务板列

我们很高兴地宣布，我们增加了一个选项，使你可以自定义任务板上的列。 现在可以对列执行添加、删除、重命名和重新排序操作。

若要配置 Taskboard 上的列，请转到 “列选项”。

Customizing columns on the taskboard.

此功能基于来自开发者社区的建议设置优先级。

切换以显示或隐藏积压工作 (backlog) 中已完成的子工作项

很多时候，在完善积压工作 (backlog) 时，你只想查看尚未完成的项目。 现在，可以显示或隐藏积压工作 (backlog) 中已完成的子项。

如果切换为启用状态，你将看到所有子项处于已完成状态。 如果切换为关闭状态，则将从积压工作 (backlog) 中隐藏所有处于已完成状态的子项。

Show or hide child items on the backlog.

现在，可以通过激活 Azure Boards 中的搜索框，轻松访问最近访问的板、积压工作、查询和冲刺。

Activate the instant search box.

此外，还可以在搜索框中键入版块名称，在项目中搜索板、积压工作、查询和冲刺。 现在，最重要的板只是点击一下。

Search for a board name.

标记工作项时显示的最近使用的标记

标记工作项时，自动完成选项现在最多可显示五个最近使用的标记。 这样，就可以更轻松地向工作项添加正确的信息。

Most recent used tags displayed when tagging a work item.

Azure Repos

改进了代码搜索筛选选项

以前，代码搜索支持 39 个代码搜索筛选器，例如 注释： 和 def：。 数据表明，未使用许多筛选器，因此我们正在删除一些筛选器并合并其他筛选器。 通过此更新，我们将筛选器数减少到 19。 这有助于提高代码搜索查询的效率，并减少界面中的混乱。

Code search filter options.

例如，现在 func：映射到方法：，即，如果搜索 func：Account管理员，结果将映射到 method：Account管理员。 同样， macrodef： 和 macroref： 映射到 macro：。 另一方面，由于缺少使用，已弃用联合和组织等筛选器。

拉取请求的代码覆盖率指标和分支策略

现在你可以在拉取请求 (PR) 视图中查看更改的代码覆盖率指标。 这可确保你已通过自动测试充分测试了更改。 覆盖率状态将在 PR 概述中显示为注释。 你可以在文件差异视图中查看更改的每个代码行的覆盖率的详细信息。

Code coverage metrics and branch policy for pull requests

View details of coverage information for every code line that is changed.

此外，存储库所有者现在可以设置代码覆盖率策略，并防止大型未经测试的更改合并到分支中。 可以在存储库根目录中检查的设置文件中定义azurepipelines-coverage.yml所需的覆盖阈值，并且可以使用现有配置分支策略来定义 Azure Repos 中其他服务功能的分支策略。

Define coverage thresholds.

筛选来自拉取请求的注释通知

拉取请求中的注释通常会由于通知而产生很多干扰信息。 我们添加了一个自定义订阅，允许你按注释期限、注释者、删除的注释、提及的用户、拉取请求作者、目标分支和对话参与者来筛选订阅的注释通知。 可以通过单击右上角的用户图标并导航到 “用户设置”来创建这些通知订阅。

Filter comment notifications from pull requests.

Filter comment notifications in User settings.

拉取请求注释的服务挂钩

现在，你可以根据存储库和目标分支为拉取请求中的注释创建服务挂钩。

Service hooks for pull request comments.

Azure Artifacts

通过公共源公开共享你的包（预览版）

你现在可以在公共源中创建和存储包。 存储在公共源中的包可供 Internet 上的所有人使用，无论它们是否在组织中，甚至登录到 Azure DevOps 组织。 在源文档中了解有关公共源的详细信息，或直接跳转到教程中公开共享包。

Share your packages with public feeds.

Azure Pipelines

kustomize 和 kompose 作为 KubernetesManifest 任务中的制作选项

kustomize（Kubernetes sig-cli 的一部分）允许你定制用于多个用途的原始的无模板的 YAML 文件，并保留初始 YAML 不变。 在 KubernetesManifest 任务的烘焙操作下添加了 kustomize 选项，以便任何包含 kustomization.yaml 文件的文件夹都可用于生成 KubernetesManifest 任务的部署操作中使用的清单文件。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kustomize
    kustomizationPath: folderContainingKustomizationFile

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

kompose 将把 Docker Compose 文件转换成 Kubernetes 资源。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    renderType: kompose
    dockerComposeFile: docker-compose.yaml

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)

支持 HelmDeploy 任务中的群集管理凭据

以前， HelmDeploy 任务使用群集用户凭据进行部署。 这会导致针对基于 Azure Active Directory、启用 RBAC 的群集收到交互式登录提示和发生管道失败。 为了解决此问题，我们添加了一个复选框，让你可以使用群集管理凭据而不是群集用户凭据。

Package and deploy Helm charts showing the use cluster admin credentials checkbox.

在 YAML 编辑器中管理管道变量

我们更新了在 YAML 编辑器中管理管道变量的体验。 不再需要使用经典编辑器来添加或更新 YAML 管道中的变量。

Manage pipeline variables in YAML editor.

YAML 管道中预定义的新变量

变量为你提供了一种简便方法，可以将关键数据位导入管道的各个部分。 通过此更新，我们已将几个预定义变量添加到部署作业。 这些变量由系统自动设置，范围限定为特定的部署作业，并且是只读的。

  • Environment.Id - 环境的 ID。
  • Environment.Name - 部署作业所针对的环境的名称。
  • Environment.ResourceId - 部署作业所针对的环境中资源 ID。
  • Environment.ResourceId - 部署作业所针对的环境中资源的名称。

目前，可以使用经典版本自动链接工作项。 但是，YAML 管道无法执行此操作。 通过此更新，我们解决了这一差距。 使用来自指定分支的代码成功运行管道时，Azure Pipelines 会自动将该运行与所有工作项相关联（这些工作项是通过该代码中的提交推断出来的）。 打开工作项时，你将能够看到在其中生成该工作项的代码的运行。 若要对此进行配置，请使用管道的“设置”面板。

取消多阶段 YAML 管道运行中的阶段

运行多阶段 YAML 管道时，现在可以取消正在执行的阶段。 如果你知道阶段将要失败，或者你将要启动另一个运行，这个操作会很有帮助。 此功能也是我们支持将来重试失败阶段的先决条件。

多阶段 YAML 管道中的审批

我们将继续改进多阶段 YAML 管道，现在允许向这些管道添加手动审批。 基础结构所有者可以保护其环境，并在向环境中部署任何管道的某个阶段之前寻求手动审批。 在基础结构（环境）和应用程序（管道）所有者之间完全隔离角色后，你将确保手动注销特定管道中的部署，并集中控制在所有部署中向环境应用相同的检查。

Approvals in multi-stage YAML pipelines.

部署到 dev 的管道运行将在阶段开始时停止以进行审批。

Pipeline runs deploying to dev will stop for approval.

托管管道映像的更新

我们对多个 Azure Pipelines 托管的 VM 映像进行了更新。 可在此处找到有关最新版本的更多详细信息。 在此更新中添加了以下更改：

  • 对于 VS2017 和 VS2019：

  • 对于 Ubuntu 16.04：

    • 更新了 helm 以始终拉最新（不再固定在 v2.14.0）
    • 添加了几个 常用的 Docker 容器
    • 已将 Python 更新为版本 2.7.16、3.4.10、3.5.7、3.6.9、3.7.4
    • 更改了 Rust 默认路径和环境变量

  • 对于所有映像，为映像版本添加了 ImageVersion 环境变量

有关可用于特定映像的工具的完整列表，请转到设置>代理池>详细信息。

对用于虚拟机的 DevOps 项目的增强

在此更新中，我们增强了 DevOps Projects 虚拟机（VM）工作流，以包含不符合每个位置配额限制的 VM。 以前，必须按名称和产品/服务选择 VM。 现在，你有一个按需视图，其中包含有关 VM 产品/服务的更多详细信息，例如成本/月、RAM、数据磁盘等。这使你能够更轻松地选择所需的虚拟机。

Enhancements to DevOps Project for virtual machine.

单个托管池

在最后一个冲刺中，我们传达说，我们将推出一个名为 Azure Pipelines 的新托管池，以替换所有其他托管池 --Hosted、Hosted VS2017、Hosted Ubuntu 1604、Hosted Windows 2019 与 VS2019、Hosted macOS 和 Hosted macOS High Sierra。 此版本将实现此更改。

有时，有多个托管池可能会令人困惑。 无法准确了解正在使用并发的情况。 例如，如果并发为 10 个并行作业，则在每个托管池中看到 10 个虚拟代理，这不准确。 当作业正在等待具有所有空闲代理的特定托管池（例如托管 VS2017）时，你可能会认为 Azure Pipelines 服务已中断，而不会意识到并发可能在其他托管池（例如 Hosted Ubuntu 1604）中使用。

通过此更改，你将看到一个托管池，该池可准确了解该池中正在运行的作业数。 我们计划在未来几个冲刺中推出这项更改。 无需对管道进行任何更改，因为我们会自动将作业从旧的托管池重定向到新统一池中的相应映像。

显示每个作业的正确池信息

以前，当你使用矩阵来扩展作业或变量来标识池时，我们在日志页中显示正确的池信息时遇到问题。 通过此更新，我们修复了导致某些作业显示不正确的池信息的问题。

用于不可靠测试管理的产品内支持

Flaky 测试可能会影响开发人员的工作效率，因为测试失败可能与测试中的更改无关。 它们还可以影响发货代码的质量。 这就是为什么我们添加了对不规则测试管理的产品内支持。 此功能支持使用检测、报告和解决的端到端生命周期。 不可靠测试管理支持系统检测和自定义检测。

系统检测可通过 VSTest 任务重新运行功能获得。 不可靠测试是一种提供不同结果（例如通过或失败）的测试，即使源代码或执行环境未发生更改。 对同一分支的测试执行的所有进一步执行也会标记为浮点，直到解析并取消标记。 还可以使用 API 插入自定义检测机制。 将测试标识为浮点后，可以在管道的上下文测试报告中获取详细信息。 然后，可以决定异常测试是否影响管道故障。 默认情况下，浮点测试信息可用作其他元数据。

In-product support for flaky test management.

下面是包含测试摘要的报表示例。

Example of a report with the test summary.

有关浮点测试管理的更多详细信息，请参阅此处的文档。

Azure 门户中 WebApp 部署中心的改进

我们改进了 Azure 门户中的 WebApp 部署中心，并支持具有多个项目的管道。 现在，如果在 Web 应用上部署了 Azure Pipelines 的非主要项目，你将从Azure 门户获取相关详细信息。 你还将提供指向已部署存储库的深层链接，以便直接从Azure 门户导航到存储库。 存储库可以托管在 Azure Repos 或 GitHub 中。

新分支的 CI 触发器

创建新分支以及该分支没有发生更改时，不触发 CI 生成是一个长时间挂起的请求。 请开考虑以下示例：

  • 使用 Web 界面基于现有分支创建新分支。 如果分支筛选器与新分支的名称匹配，这将立即触发新的 CI 生成。 这是不需要的，因为新分支的内容与现有分支的内容相同。
  • 你有一个包含两个文件夹的存储库 - 应用和文档。设置 CI 的路径筛选器以匹配“app”。 换句话说，如果已将更改推送到文档，则不希望创建新的生成。在本地创建新分支，对文档进行一些更改，然后将该分支推送到服务器。 我们曾经触发过一个新的 CI 生成。 这是不需要的，因为你明确要求不在 docs 文件夹中查找更改。 但是，由于我们处理新分支事件的方式，看起来就像更改了 app 文件夹一样。

现在，我们有了更好的方法来处理新分支的 CI，以解决这些问题。 当你发布新分支时，我们在该分支中显式查找新提交，并检查它们是否与路径筛选器匹配。

Terraform 与 Azure Pipelines 集成

Terraform 是一种开放源代码工具，用于安全高效地开发、更改和版本化基础结构。 Terraform 将 API 编码为声明性配置文件，从而使你可以使用高级配置语言来定义和配置基础结构。 可以使用 Terraform 扩展跨所有主要基础结构提供商创建资源：Azure、Amazon Web Services（AWS）和 Google Cloud Platform （GCP）。

若要详细了解 Terraform 扩展，请参阅此处的文档。

Terraform integration with Azure Pipelines.

与 Google Analytics 的集成

借助 Google Analytics 试验框架，你可以测试网站或应用的几乎任何更改或变体，以衡量其对特定目标的影响。 例如，你可能有一些希望用户完成的活动（例如购物、订阅时事快报）和/或想要改进的指标（例如收入、会话持续时间、跳出率）。 通过这些活动，你可以根据对功能性能的直接影响来确定值得实现的更改。

适用于 Azure DevOps 的 Google Analytics 试验扩展将试验步骤添加到了生成和发布管道中，因此你可以通过连续地管理试验来不断地进行迭代、学习和部署，同时从 Azure Pipelines 中获得所有 DevOps 权益。

你可以从市场下载 Google Analytics 试验扩展。

Integration with Google Analytics.

管道缓存（公共预览版）

通过管道缓存，可以保存长时间运行的操作（如包还原或依赖项编译）的结果，并在下次运行管道期间将其还原。 这可能会导致生成速度更快。

有关更多详细信息，请参阅博客文章，其中提供了完整的公告。

管道变量组和变量管理命令

将基于 YAML 的管道从一个项目移植到另一个项目可能会很困难，因为需要手动设置管道变量和变量组。 但是，借助管道变量组和变量管理命令，你现在可以编写管道变量和变量组的设置和管理脚本，然后对这些变量和变量组进行版本控制，从而轻松共享从一个项目到另一个项目移动和设置管道的指令。

为 PR 分支运行管道

在创建 PR 时，验证这些更改是否会中断目标分支上运行的管道可能会很困难。 但是，通过为某个 PR 分支触发管道运行或出于生成目的进行排队的功能，现在可以通过针对目标管道运行更改来验证和直观了解将要进行的更改。 有关详细信息，请参阅 az pipelines run 和 az pipelines build queue 命令文档。

跳过第一个管道运行

创建管道时，有时你想要创建和提交 YAML 文件，而不是触发管道运行，因为它可能会导致由于各种原因而运行错误 - 基础结构未就绪或需要创建和更新变量/变量组等。使用 Azure DevOps CLI，现在可以通过包括 --skip-first-run 参数来跳过创建管道时的第一个自动化管道运行。 有关更多信息，请参阅 az 管道创建命令文档。

服务终结点命令增强

服务终结点 CLI 命令之前仅支持 azure rm 和 github 服务终结点设置和管理。 但是，在此版本中，使用服务终结点命令可以通过使用文件提供配置来创建任何服务终结点，并提供优化的命令：az devops service-endpoint github 和 az devops service-endpoint azurerm，它们可为创建这些类型的服务终结点提供一流的支持。 有关详细信息，请参阅命令文档。

后续步骤

注意

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

前往 Azure DevOps 并了解一下。

转到 Azure DevOps

如何提供反馈

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

Make a suggestion

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

此致

山姆·古肯海默