限制工作项状态转换

  • 项目

经过多个冲刺预览版后，我们现在向所有客户宣布正式发布 状态转换限制规则 ，作为 Sprint 172 更新的一部分。

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

功能

Azure Boards

Azure Pipelines

Azure Artifacts

Azure Boards

状态转换限制规则

经过多次冲刺个人预览版后，状态转换限制规则现已面向所有客户正式发布。 使用此新工作项类型规则，可以限制工作项从一个状态移动到另一个状态。 例如，可以限制 Bug 从“新建”到“已解决”。 相反，它们必须从“新建 -> 活动 -> 已解决”

此示例将 Bug 限制为从“新”状态转到“活动”，然后从“已解决”状态转到“已解决”，而不是从“新建”状态转到“已解决” 状态。

还可以创建规则，按组成员身份限制状态转换。 例如，只有“审批者”组中的用户才能从“新建 -> 已批准”移动用户情景。

复制工作项以复制子项

Azure Boards最需要的功能之一是能够复制同时复制子工作项的工作项。 在此冲刺中，我们在复制工作项对话框中添加了一个新选项，用于“包括子工作项”。 选中此选项后，将复制工作项并复制所有子工作项， (最多 100) 。

此页显示Azure Boards“在复制的工作项中包含子工作项”中的新选项。

改进了已激活字段和已解析字段的规则

到目前为止， “激活者”、“ 激活日期”、“ 解决者”和“ 解决日期 ”的规则一直是个谜。 它们仅为系统工作项类型设置，并且特定于状态值“Active”和“Resolved”。 在冲刺 172 中，我们更改了逻辑，使这些规则不再针对特定状态。 相反，它们由状态所在的类别 (状态类别) 触发。 例如，假设你在“已解决”类别中有一个自定义状态“需要测试”。 当工作项从“活动”更改为“需要测试”时，将触发 “解决者 ”和“ 解决日期” 规则。

这样，客户就可以创建任何自定义状态值，并且仍生成“ 激活者”、“ 激活日期”、“ 解决者”和“ 解析日期” 字段，而无需使用自定义规则。

积压工作和板上的系统工作项类型 (个人预览版)

自继承过程模型启动以来，已将多个工作项类型排除在添加到板和积压工作之外。 这些工作项类型包括：

进程 工作项类型
敏捷 问题
Scrum 障碍
CMMI 更改请求
问题
审阅
风险

从此冲刺开始，我们将允许那些希望在任何积压工作级别上提供这些工作项类型的客户提供个人预览版。

使用此Azure Boards页，将以前排除的工作项类型添加到版块和积压工作。

如果你有兴趣预览此功能，请 向我们发送电子邮件 ，并提供你的组织名称，我们可以为你提供访问权限。

Azure Pipelines

独占部署锁定策略

通过此更新，可以确保一次只有一个运行部署到环境。 通过在环境中选择“独占锁”检查，只会继续一次运行。 要部署到该环境的后续运行将暂停。 使用排他锁的运行完成后，最新运行将继续。 将取消任何中间运行。

在“添加检查”页中，选择“独占锁”以确保一次只有一个运行部署到环境。

管道资源触发器的阶段筛选器

在此冲刺中，我们添加了对“阶段”的支持，作为 YAML 中管道资源的筛选器。 使用此筛选器，无需等待整个 CI 管道完成以触发 CD 管道。 现在可以选择在 CI 管道中的特定阶段完成后触发 CD 管道。

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:            ### This stage filter is used when evaluating conditions for triggering your CD pipeline
      - PreProduction    ### stages are AND'ed. On successful completion of all the stages provided, your CD pipeline will be triggered. 
      - Production

在 CI 管道中成功完成触发器筛选器中提供的阶段后，会自动为 CD 管道触发新的运行。

YAML 管道的基于 Webhook 的通用触发器

目前，我们拥有各种资源 (，例如管道、容器、生成和包) ，通过这些资源可以使用项目并启用自动触发器。 但是，到目前为止，你无法根据其他外部事件或服务自动执行部署过程。 在此版本中，我们将在 YAML 管道中引入 Webhook 触发器支持，以实现管道自动化与任何外部服务的集成。 可以通过其 Webhook 订阅任何外部事件， (GitHub、GitHub Enterprise、Nexus、Aritfactory 等) 并触发管道。

下面是配置 Webhook 触发器的步骤：

  1. 在外部服务上设置 Webhook。 创建 Webhook 时，需要提供以下信息：

    • 请求 URL - “https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>？api-version=6.0-preview”
    • 机密 - 这是可选的。 如果需要保护 JSON 有效负载，请提供 “机密” 值

  2. 创建新的“传入 Webhook”服务连接。 这是新引入的服务连接类型，可用于定义三条重要信息：

    • Webhook 名称：Webhook 的名称应与在外部服务中创建的 Webhook 匹配。
    • HTTP 标头 - 请求中 HTTP 标头的名称，其中包含用于请求验证的有效负载哈希值。 例如，对于 GitHub，请求标头将为“X-Hub-Signature”
    • 机密 - 机密用于分析用于验证传入请求的有效负载哈希， (这是可选的) 。 如果在创建 Webhook 时使用了机密，则需要提供相同的密钥

    在“编辑服务连接”页中，配置 Webhook 触发器。

  3. YAML 管道中引入了名为 webhooks 的新资源类型。 若要订阅 Webhook 事件，需要在管道中定义 Webhook 资源，并将其指向传入 Webhook 服务连接。 还可以基于 JSON 有效负载数据在 Webhook 资源上定义其他筛选器，以进一步自定义每个管道的触发器，并且可以在作业中以变量的形式使用有效负载数据。

resources:
  webhooks:
    - webhook: MyWebhookTrigger          ### Webhook alias
      connection: MyWebhookConnection    ### Incoming webhook service connection
      filters:
        - path: repositoryName      ### JSON path in the payload
          value: maven-releases     ### Expected value in the path provided
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    ### JSON payload data is available in the form of ${{ parameters.<WebhookAlias>.<JSONPath>}}
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}
  1. 每当传入 Webhook 服务连接收到 Webhook 事件时，将为订阅 Webhook 事件的所有管道触发新的运行。

YAML 资源触发器问题支持和可跟踪性

当管道触发器无法按预期执行时，可能会造成混淆。 为了帮助更好地了解这一点，我们在管道定义页中添加了一个名为“触发器问题”的新菜单项，其中显示了有关触发器未执行的原因的信息。

资源触发器可能由于两个原因而无法执行。

  1. 如果提供的服务连接的源无效，或者触发器中存在任何语法错误，则根本不会配置触发器。 这些错误显示为错误。

  2. 如果触发器条件不匹配，则不会执行触发器。 每当发生这种情况时，都会显示一条警告，以便你可以了解条件不匹配的原因。

    此名为“触发器问题”的管道定义页显示有关触发器未运行的原因的信息。

我们在管道页中添加了警告横幅，提醒用户注意你所在区域中发生的可能影响管道的事件。

Azure Artifacts

能够从 UI 创建组织范围的源

我们恢复了客户通过 Web UI 为本地和托管服务创建和管理组织范围的源的能力。

现在，可以通过 UI 创建组织范围的源，方法是转到“项目 -> 创建源”，并在“作用域”中选择一种源类型。

通过依次选择“项目”、“创建源”和“作用域”中的源类型来创建组织范围的源。

虽然我们建议使用项目范围的源，以便与 Azure DevOps 产品/服务的其余部分保持一致，但你可以再次通过 UI 和各种 REST API 创建、管理和使用组织范围的源。 有关详细信息，请参阅我们的源文档。

后续步骤

注意

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

前往 Azure DevOps 并查看。

转到 Azure DevOps

如何提供反馈

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

提出建议

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

此致

亚伦·霍尔伯格