预览和审批部署
现在，你已了解管道各阶段，以及如何添加管道阶段来验证 Bicep 代码。 对部署建立信心的下一步是添加另一个阶段，以准确检查部署将更改的内容。
在此单元中，你将了解如何在管道中使用 What-if 命令。 还将了解如何添加审批，以便可以在部署运行前手动验证命令的输出。
What-if 操作
Bicep 文件描述了你希望 Azure 环境在部署结束时所处的状态。 当你提交部署时，Azure 资源管理器会更改 Azure 环境以匹配 Bicep 文件中所述的状态。
部署可能会导致将新资源部署到环境中，或更新现有资源。 以完整模式运行部署时，甚至可能导致删除现有资源。
在创建、更新或删除资源时，情况有可能发生意想不到的改变。 良好的做法是添加一个额外的步骤来验证将创建、更新和删除的资源。 此验证使自动化过程更有价值。 在部署到生产环境时，确认将对环境进行的任何更改很重要。
资源管理器提供 What-if 操作，可以在管道阶段中对 Bicep 文件运行该操作：
可以在管道定义中使用 az deployment group what-if Azure CLI 命令来运行 What-if 步骤：
stages:
- stage: Preview
jobs:
- job: Preview
steps:
- task: AzureCLI@2
inputs:
azureSubscription: 'MyServiceConnection'
scriptType: 'bash'
scriptLocation: 'inlineScript'
inlineScript: |
az deployment group what-if \
--resource-group $(ResourceGroupName) \
--template-file deploy/main.bicep
提示
在本模块中，我们使用 Azure CLI 来运行 What-if 操作。 如果生成自己的基于 PowerShell 的管道，则可以将 New-AzResourceGroupDeployment cmdlet 与 -Whatif 开关一起使用，或者可以使用 Get-AzResourceGroupDeploymentWhatIfResult cmdlet。
What-if 操作不会对环境进行任何更改。 而它描述了将创建或删除的资源、将更新的资源属性以及将删除的资源。
有时，What-if 会显示资源将发生更改，但实际上并不会发生。 这种反馈被称为“干扰信息”。 我们正在努力减少这些问题，但我们需要大家的帮助来报告这些问题。
看到 What-if 操作的输出后，可以确定是否继续执行部署。 这一步通常涉及人工评审 What-if 命令的输出，然后确定所识别的更改是否合理。 如果人工审阅者确定更改合理，他们可以手动批准管道运行。
若要了解有关 What-if 命令的详细信息，请参阅 Microsoft Learn 模块使用 What-if 预览 Azure 部署更改。
环境
在 Azure Pipelines 中，环境表示解决方案部署到的位置。 环境提供了有助于处理复杂部署的功能。 以后的模块将详细介绍环境及其功能。 现在，我们将重点介绍如何向管道添加手动审批。
如你所知，可以使用作业来定义管道阶段中的一系列步骤。 在管道中包含环境时，需要使用一种特殊类型的作业，称为“部署作业”。 部署作业类似于常规作业，但它提供了一些额外功能。 功能包括定义部署作业所使用的环境：
variables:
- name: deploymentDefaultLocation
value: westus3
stages:
- stage: Preview
jobs:
- job: Preview
steps:
- task: AzureCLI@2
inputs:
azureSubscription: 'MyServiceConnection'
scriptType: 'bash'
scriptLocation: 'inlineScript'
inlineScript: |
az deployment group what-if \
--resource-group $(ResourceGroupName) \
--template-file deploy/main.bicep
- stage: Deploy
jobs:
- deployment: Deploy
environment: MyAzureEnvironment
strategy:
runOnce:
deploy:
steps:
- checkout: self
- task: AzureResourceManagerTemplateDeployment@3
name: Deploy
displayName: Deploy to Azure
inputs:
connectedServiceName: 'MyServiceConnection'
location: $(deploymentDefaultLocation)
resourceGroupName: $(ResourceGroupName)
csmFile: deploy/main.bicep
请注意，在部署作业的 YAML 定义中，与常规作业存在一些主要区别：
- 部署作业不是以单词
job开头，而是定义为deployment。 environment关键字指定要面向的环境的名称。 在前面的示例中，是针对名为MyAzureEnvironment的环境跟踪部署的。strategy关键字指定 Azure Pipelines 运行部署步骤的方式。 部署策略支持复杂的部署过程，尤其是存在多个生产环境的情况。 在此模块中，我们使用runOnce部署策略。 此策略行为与你已习惯的其他作业类似。
阶段检查和审批
创建环境后，可以定义检查。 检查用于验证在管道可以使用环境之前必须满足的条件。 审批是一种检查类型，需要人工提供手动审批。
检查是针对环境而不是管道定义的。 管道 YAML 文件的作者无法删除或添加这些检查和审批。 只有环境的管理员可以管理该环境的检查和审批。
在许多组织中，Azure Pipelines 中环境的所有者负责其部署到环境。 检查和审批可帮助确保适当的人员参与部署过程。
检查和审批的工作原理是什么？
在即将开始管道阶段之前评估检查和审批。 当 Azure Pipelines 即将运行某管道阶段时，它会查看该阶段使用的所有管道资源，包括环境。 环境可以具有需要满足的检查。
审批是一种检查类型。 配置审批检查时，需要指定一个或多个需要批准管道继续执行的用户。
Azure Pipelines 还提供其他类型的检查。 例如，可以调用 API 来运行一些自定义逻辑、控制阶段可运行的营业时间，甚至查询 Azure Monitor 以确保部署成功。 在本模块中，我们仅讨论审批检查，但我们在总结中提供了指向检查详细信息的链接。
注意
代理池和服务连接也可以配置检查。 还可使用称为手动审批任务的特殊步骤。 但在本模块中，我们将重点介绍环境及其关联的检查。
管道开始并到达需要审批检查的阶段后，管道运行将暂停。 所有被指定为审批者的用户都会在 Azure DevOps 中通过电子邮件收到一条消息。
审批者可以检查管道日志，例如 What-if 操作检测到的更改。 然后，他们根据此信息批准或拒绝更改。 如果他们批准更改，管道将继续运行。 如果他们拒绝，或者如果在可配置的超时期限内未响应，则阶段将失败。
良好做法的重要性
借助 Azure Pipelines 中的环境功能可将部署关联到环境，然后部署将继承环境所有者定义的检查和审批。 但是，不需要新管道使用环境。
你和你的组织要建立良好做法来评审管道定义，这一点很重要。 例如，通过使用分支保护策略，将存储库配置为要求对主分支的任何更改进行拉取请求评审。 以后的模块将对此概念进行详细介绍。
还可以向服务连接添加检查和审批，确保在部署可以使用服务主体的凭据之前获得批准。 但是，审批也会影响管道运行预检验证和 What-if 操作的能力，因为它们也需要服务连接。
可以针对 What-if 阶段使用另一个单独的服务连接及其自己的服务主体。 用于预检和验证阶段的服务主体需要定义一个自定义 Azure 角色，以确保它获得完成工作所需的最低权限。