预览和审批部署
你现已了解工作流作业，以及如何添加工作流作业来验证 Bicep 代码。 对部署建立信心的下一步是添加另一个作业，以准确检查部署将更改的内容。
在此单元中，你将了解如何在工作流中使用 What-if 命令。 还将了解如何添加环境保护规则，以便可以在部署运行前手动验证命令的输出。
What-if 操作
Bicep 文件描述了你希望 Azure 环境在部署结束时所处的状态。 当你提交部署时，Azure 资源管理器会更改 Azure 环境以匹配 Bicep 文件中所述的状态。
部署可能会导致将新资源部署到环境中，或更新现有资源。 以完整模式运行部署时，甚至可能导致删除现有资源。
任何时候创建、更新或删除资源时，情况都有可能以你意想不到的方式发生改变。 良好的做法是添加一个额外的步骤来验证将创建、更新和删除的内容。 此验证使自动化过程更有价值。 在部署到生产环境时，请务必确认将对环境进行的任何更改。
资源管理器提供 What-if 操作，可在工作流作业中对 Bicep 文件运行该操作：
arm-deploy 操作支持使用 additionalArguments 属性触发 What-if 操作：
jobs:
preview:
runs-on: ubuntu-latest
needs: [lint, validate]
steps:
- uses: azure/login@v1
name: Sign in to Azure
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/arm-deploy@v1
name: Run what-if
with:
failOnStdErr: false
resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
template: deploy/main.bicep
parameters: >
environmentType=${{ env.ENVIRONMENT_TYPE }}
additionalArguments: --what-if
突出显示的代码等效于使用 Azure CLI 运行部署，其中包含 --what-if 参数。
What-if 操作不会对环境进行任何更改。 而是描述了将创建的资源、将更新的资源属性以及将删除的资源。
有时，What-if 会显示资源将发生更改，但实际上并不会发生。 这种类型的输出称为“干扰”。 我们正在努力减少这些问题，但需要大家的帮助。 报告 What-if 问题。
看到 What-if 操作的输出后，可以确定是否继续执行部署。 这一步通常涉及人工评审 What-if 命令的输出，然后确定所识别的更改是否合理。 如果人工审阅者确定更改是合理的，则他们可手动批准工作流运行。
若要了解有关 What-if 命令的详细信息，请参阅 Microsoft Learn 模块使用 What-if 预览 Azure 部署更改。
环境
在 GitHub Actions 中，“环境”表示部署解决方案的位置。 环境提供了有助于处理复杂部署的功能。 以后的模块将详细介绍环境及其功能。 现在，我们将重点介绍用于向工作流添加所需审查者的功能。
你通过使用 GitHub Web 界面来创建环境。 使用公用 GitHub 存储库时，或使用 GitHub Enterprise 帐户时，都可以创建环境。
创建环境后，可在工作流中的任何作业中引用该环境：
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: 'Lint Bicep template'
run: az bicep build --file deploy/main.bicep
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- uses: azure/login@v1
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/arm-deploy@v1
with:
deploymentName: ${{ github.run_number }}
resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
template: ./deploy/main.bicep
parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
deploymentMode: Validate
deploy:
runs-on: ubuntu-latest
environment: MyAzureEnvironment
needs: [lint, validate]
steps:
- uses: actions/checkout@v3
- uses: azure/login@v1
with:
client-id: ${{ secrets.AZURE_CLIENT_ID }}
tenant-id: ${{ secrets.AZURE_TENANT_ID }}
subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
- uses: azure/arm-deploy@v1
with:
deploymentName: ${{ github.run_number }}
resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
template: ./deploy/main.bicep
parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}
注意
当部署工作流的工作负载标识在环境中与资源管理器交互时，它需要一个配置有环境名称的联合凭据。 后续模块将对各种环境进行详细介绍。 运行本模块的练习时，将创建必要的联合凭据。
环境保护规则
创建环境后，可定义保护规则。 保护规则用于验证在某个步骤可以使用环境之前必须满足的条件。 “必需审阅者”保护规则是一种要求人工提供手动审批的检查类型。
保护规则是针对环境而不是工作流定义的。 工作流 YAML 文件的作者不能删除或添加这些保护规则。 只有存储库的管理员或帐户所有者可管理环境及其保护规则。
环境保护规则可帮助确保适当的人员参与部署过程。
环境保护规则的工作原理是怎样的？
将环境与步骤相关联时，将在步骤开始之前评估环境的保护规则。
“必需审阅者”是一种保护规则。 配置“必需审阅者”保护规则时，分配一个或多个 GitHub 用户，他们需要批准继续工作流。
环境还提供其他类型的保护规则。 例如，可限制能部署到特定环境的 Git 分支。 我们在此模块中仅讨论“必需审阅者”规则，但我们在摘要中提供了指向其他保护规则的更多信息的链接。
工作流开始并到达需要审阅者的步骤后，工作流运行将暂停。 所有被指定为审查者的用户都会在 GitHub 中通过电子邮件收到一条消息。
审阅者可检查工作流日志，例如 What-if 操作检测到的更改。 然后，他们根据此信息批准或拒绝更改。 如果他们批准更改，工作流将继续运行。 如果他们拒绝，或者他们在超时期限内没有回应，则作业失败。
良好做法的重要性
通过 GitHub 的环境功能，你可将部署链接到环境，然后部署将继承环境管理员定义的保护规则。 但不需要新工作流使用环境。
组织要建立良好的做法来评审工作流定义，这一点很重要。 例如，通过使用分支保护规则，将存储库配置为要求对主分支上的任何更改进行拉取请求审查。 以后的模块将对此概念进行详细介绍。
还可将机密添加到环境。 这样，机密只能在也使用该环境的作业中使用。 通过组合使用环境保护规则和机密，可确保维护工作流安全性。