限制工作项状态转换
在预览版中推出多个冲刺后，我们现已宣布正式发布 状态转换限制规则，作为 Sprint 172 更新的一部分，向所有客户发布状态转换限制规则 。
有关详细信息， 请查看下面的功能 列表。
功能
Azure Boards
Azure Pipelines
Azure Artifacts
Azure Boards
状态转换限制规则
在几个个人预览版冲刺之后，状态转换限制规则现已适用于所有客户。 使用此新的工作项类型规则，可以限制工作项从一个状态移动到另一个状态。 例如，可以限制 Bug 从“新建”转到“已解决”。 相反，它们必须从“新建 -> 活动” -> “已解决”
还可以创建规则来限制组成员身份的状态转换。 例如，只有“审批者”组中的用户才能从“新建 -> 已批准”移动用户情景。
复制工作项以复制子级
Azure Boards 最请求的功能之一是复制同时复制子工作项的工作项。 在此冲刺中，我们向复制工作项对话框添加了“包括子工作项”的新选项。 选中此选项后，将复制工作项并复制所有子工作项（最多 100 个）。
改进了已激活和已解析字段的规则
到目前为止，“已激活日期”、“已激活日期”、“已解决日期”和“已解决日期”的规则一直是个谜。 它们仅针对系统工作项类型进行设置，特定于“Active”和“Resolved”的状态值。 在冲刺 172 中，我们更改了逻辑，以便这些规则不再针对特定状态。 相反，它们由状态所在的类别（状态类别）触发。 例如，假设你在“已解决”类别中有“需要测试”的自定义状态。 当工作项从“活动”更改为“需要测试”时， 将触发“已解决者 ”和 “已解决日期 ”规则。
这样，客户就可以创建任何自定义状态值，并且仍生成“已激活的日期”、“已解决日期”和“已解析日期”字段，而无需使用自定义规则。
积压工作和板上的系统工作项类型（个人预览版）
自继承过程模型开始以来，已排除了多个工作项类型，无法添加到板和积压工作。 这些工作项类型包括：
| 处理 | 工作项类型 |
|---|---|
| 敏捷 | 问题 |
| Scrum | 障碍 |
| CMMI | 更改请求 |
| 问题 | |
| 审阅 | |
| 风险 |
从此冲刺开始，我们将允许那些希望使这些工作项类型在任何积压工作级别上可用的客户提供个人预览版。
如果你有兴趣预览此功能，请使用 你的组织名称向我们发送电子邮件 ，我们可以为你提供访问权限。
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、Artifactory 等）订阅任何外部事件，并触发管道。
下面是配置 Webhook 触发器的步骤：
在外部服务上设置 Webhook。 创建 Webhook 时，需要提供以下信息：
- 请求 URL - “https://dev.azure.com/<ADO 组织>/_apis/public/distributedtask/webhooks/<WebHook 名称>？api-version=6.0-preview”
- 机密 - 这是可选的。 如果需要保护 JSON 有效负载，请提供 机密 值
创建新的“传入 Webhook”服务连接。 这是一种新引入的服务连接类型，可让你定义三个重要信息片段：
- Webhook 名称：Webhook 的名称应与在外部服务中创建的 Webhook 匹配。
- HTTP 标头 - 请求中包含请求验证的有效负载哈希值的请求中的 HTTP 标头的名称。 例如，对于 GitHub，请求标头将为“X-Hub-Signature”
- 机密 - 机密用于分析用于验证传入请求的有效负载哈希（这是可选的）。 如果在创建 Webhook 时使用了机密，则需要提供相同的密钥
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}}
- 每当传入 Webhook 服务连接收到 Webhook 事件时，将为订阅 Webhook 事件的所有管道触发新的运行。
YAML 资源触发器问题支持和可跟踪性
当管道触发器无法按预期执行时，可能会让人困惑。 为了帮助更好地了解这一点，我们在管道定义页中添加了一个名为“触发器问题”的新菜单项，其中显示了有关触发器不执行的原因的信息。
资源触发器由于两个原因而无法执行。
如果所提供的服务连接的源无效，或者触发器中存在任何语法错误，则根本不会配置触发器。 这些作为错误浮出水面。
如果触发器条件不匹配，触发器将不会执行。 每当发生这种情况时，都会显示警告，以便你可以了解条件不匹配的原因。
影响管道的实时站点事件的横幅
我们在管道页中添加了警告横幅，提醒用户区域中正在进行的事件，这可能会影响管道。
Azure Artifacts
能够从 UI 创建组织范围的源
我们正在恢复客户通过本地服务和托管服务的 Web UI 创建和管理组织范围的源的能力。
现在，可以通过 UI 创建组织范围的源，方法是转到“项目 -> 创建源”并选择“作用域”中的源类型。
虽然我们建议使用项目范围的源与 Azure DevOps 产品/服务的其余部分一致，但你可以再次通过 UI 和各种 REST API 创建、管理和使用组织范围的源。 有关详细信息，请参阅我们的源文档。
后续步骤
注意
这些功能将在未来两到三周内推出。
前往 Azure DevOps 并了解一下。
如何提供反馈
我们很想听听你对这些功能的看法。 使用帮助菜单报告问题或提供建议。
你还可以在 Stack Overflow 上获得社区的建议和问题的答案。
此致
亚伦·霍尔伯格