适用于 Slack 的新 Analytics 报表和Azure Boards应用 - Sprint 155 更新

  • 项目

在 Sprint 155 Azure DevOps 更新中，我们将引入新的Azure Boards报表，以便更轻松地跟踪重要的团队指标。 你将在Boards、积压工作和冲刺中心的“分析”选项卡下看到新报告。 这些报表是完全交互式的，允许你调整它们以满足你的需求。

此外，我们很高兴宣布适用于 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最少的努力。

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

指标（如冲刺烧毁、工作流和团队速度）可让你了解团队的进度，并帮助回答以下问题：

  • 在这个冲刺中，我们剩下多少工作？ 我们是否有望完成它？
  • 开发过程哪一步花费的时间最长？ 我们能做点什么吗？
  • 根据以前的迭代，我们应该为下一个冲刺计划多少工作？

注意

前面显示在标题中的图表已替换为这些增强型报表。

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

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

    Analytics tab in Sprint hub.

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

    CFD and velocity reports in boards.

使用新报表时，你拥有有关团队的更多控制和信息。 下面是一些示例：

  • Sprint Burndown 和 Velocity 报表可以设置为使用工时项计数或剩余工时的总和。
  • 可以调整冲刺烧毁的时间范围，而不会影响项目日期。 因此，如果你的团队通常花在每个冲刺规划的第一天，你现在可以匹配图表来反映这一点。
  • 燃烧图现在有一个水印显示周末。
  • 通过CFD报表，可以删除设计等板列，以便更专注于团队所控制的流程。

下面是一个显示过去 30 天故事积压工作流的CFD报表示例。

Example of the CFD report.

现在可以跟踪所有积压工作级别的速度图表。 例如，现在可以同时添加“功能和史诗”，而在上一个图表仅支持“要求”之前。 下面是功能积压工作的最后 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.

此功能是根据开发者社区的建议确定优先级的。

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

很多时候，在优化积压工作时，你只想看到尚未完成的项目。 现在，你能够在积压工作上显示或隐藏已完成的子项。

如果切换处于打开状态，你将看到所有处于已完成状态的子项。 切换关闭后，所有处于已完成状态的子项都将从积压工作中隐藏。

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：AccountAdmin，结果将映射到 method：AccountAdmin。 同样 ，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 保持不变。 Kustomize 选项已在 KubernetesManifest 任务的 烘焙操作下添加，以便任何包含 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.ResourceName - 部署作业针对的环境中的资源的名称。

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

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

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

多阶段 YAML 管道中的审批

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

Approvals in multi-stage YAML pipelines.

部署到开发人员的管道将在阶段开始时停止审批。

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 Project增强功能

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

Enhancements to DevOps Project for virtual machine.

单个托管池

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

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

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

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

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

对 flaky 测试管理的产品内支持

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

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

In-product support for flaky test management.

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

Example of a report with the test summary.

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

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

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

新分支的 CI 触发器

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

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

现在，我们有一种更好的方法来处理 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 pipeline create 命令文档 。

服务终结点命令增强

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

后续步骤

注意

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

前往Azure DevOps，看一看。

转到Azure DevOps

如何提供反馈

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

Make a suggestion

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

此致

Sam Guckenheimer