部署门限
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
门限允许自动收集来自外部服务的健康信号，然后在所有信号成功或超时停止部署时促进发布。 通常，连接中使用的门限与事件管理、问题管理、更改管理、监视和外部批准系统相连接。
用例
部署门限的一些常见用例包括：
- 事件管理：在继续部署之前，请确保满足某些条件。 例如，确保不存在优先级为零的 bug 时才进行部署。
- 寻求审批：通过与 Microsoft Teams 或 Slack 等其他服务集成，通知外部用户（法律部门、审计员或 IT 经理）有关部署的信息并等待审批。
- 质量验证：查询管道指标（如通过率或代码覆盖率），仅当它们处于预定义阈值内时才进行部署。
- 安全扫描：执行项目扫描、代码签名和策略检查等安全检查。 部署门限可能会启动扫描并等待扫描完成，或仅检查是否完成。
- 相对于基线的用户体验：使用产品遥测，确保用户体验没有从基线状态回退。 部署前的用户体验指标可用作基线。
- 更改管理：等待 ServiceNow 等系统中的更改管理过程完成，然后继续部署。
- 基础结构运行状况：部署后执行监视并根据合规性规则验证基础结构，或等待资源使用正常消息和肯定的安全报告。
大多数运行状况参数会随时间而变化，定期将其状态从“正常”更改为“不正常”，再更改回“正常”。 为了解释此类变化，将定期重新评估所有门限，直到所有门限同时取得成功。 如果在配置超时前，所有门限都未在相同的时间间隔内成功，则不会继续进行发布执行和部署。
为阶段定义门限
可以在阶段开始时（预部署条件）启用门限和/或阶段结束时（部署后条件）启用门限。 有关更多详细信息，请参阅设置门限。
评估前延迟是门限评估过程开始时的时间延迟，它允许门限初始化、稳定并开始为当前部署提供准确的结果。 有关更多详细信息，请参阅门限评估流。
- 对于部署前门限，延迟是针对所部署项目记录所有 bug 所需的时间。
- 对于部署后门限，延迟将是部署的应用达到稳定运行状态所花费的最长时间、在部署阶段执行所有所需测试所花费的时间，以及部署后记录事件所花费的时间。
默认情况下，以下入口可用：
- 调用 Azure 函数：触发 Azure 函数的执行，并确保成功完成。 有关详细信息，请参阅 Azure 函数任务。
- 查询 Azure 监视警报：观察为活动警报配置的 Azure 监视警报规则。 有关详细信息，请参阅 Azure Monitor 任务。
- 调用 REST API：调用 REST API 并在返回成功响应后继续。 有关详细信息，请参阅调用 REST API 任务。
- 查询工作项：确保查询返回的匹配工作项数量在阈值内。 有关详细信息，请参阅查询工作项任务。
- 安全性与合规性评估：评估给定订阅和资源组范围内资源的 Azure Policy 合规性，也可以选择在特定资源级别进行评估。 有关详细信息，请参阅检查 Azure Policy 合规性任务。
还使用市场扩展创建自己的门。
适用于所有门限的评估选项包括：
- 门限重新评估之间的时间。 门限的连续评估之间的时间间隔。 在每个采样间隔内，会将新请求同时发送到每个门限，并评估新结果。 建议采样间隔大于已配置门限的最长典型响应时间，以便有时间接收所有响应进行评估。
- 在此之后门限将失败的超时。 所有门限的最长评估期。 如果在同一采样间隔内所有入口都成功之前已达到超时时间，则部署将被拒绝。
- 门限和审批。 如果同时配置了门限和审批，请选择所需的执行顺序。 对于预部署条件，默认设置是先提示手动（用户）审批，然后评估门限。 这样，系统就可以在发布遭到用户拒绝时评估门限函数。 对于部署后条件，默认设置是仅当所有门限都成功时，才评估门限并提示手动审批。 这可确保审批者掌握审批所需的所有信息。
有关门限分析的详细信息，请参阅查看审批日志和监视和跟踪部署。
门限评估流示例
下图演示了门限评估流，其中，在初始稳定延迟期和三个采样间隔之后，部署获得批准。
下图演示了门限评估流，其中，在初始稳定延迟期之后，并非所有门限都在每个采样间隔内取得成功。 在这种情况下，一旦超时期限到期后，部署将遭到拒绝。
