部署后测试资源

6 分钟

通过验证和预览 Bicep 部署，你已对 Bicep 文件将成功部署充满信心。但部署并不是故事的全部。部署完成后，检查部署是否按预期运行也会很有用。

在本单元中，你将了解部署完成后可运行的测试。你还将了解情况没有如你所愿时如何回退部署。

运行冒烟测试和负面测试

在 Bicep 文件中定义资源时，你的目标不仅仅是在 Azure 中创建资源。还要在满足组织要求的同时向组织传递价值。验证和预览 Bicep 文件时，你确信资源定义是有效的。但不一定知道资源实际上会不会执行所需的操作。

例如，假设你要使用 Bicep 部署工作流来部署新的 Azure SQL 逻辑服务器。服务器的 Bicep 定义是有效的，因此它通过了 Linter 和预检验证作业。 What-if 命令显示将创建一个服务器，这正是你所期望的。部署也成功完成。但在部署过程结束时，你可能仍然没有一个现成可用的数据库服务器。原因可能包括：

尚未配置防火墙规则以允许网络流量到达服务器。
你在不应在服务器上启用 Microsoft Entra 身份验证时执行了此操作，或在应启用时未执行。

即使只是在部署基本的 Bicep 文件，也值得考虑如何验证部署的资源是否确实有效并满足要求。以下是有关如何应用此原则的示例：

部署网站时，尝试从工作流进入 Web 应用程序。验证工作流是否成功连接到网站并收到有效的响应代码。
在部署内容交付网络 (CDN) 时，请尝试通过 CDN 连接到资源。验证工作流是否成功连接到 CDN 并收到有效的响应代码。

这些测试有时称为“基础结构冒烟测试”。冒烟测试是一种简单的测试形式，旨在发现部署中的主要问题。

注意

某些 Azure 资源不易从 GitHub 托管的运行程序访问。如果要求通过专用网络访问资源，则可能需要考虑使用自承载运行程序来运行冒烟测试作业。

执行负面测试也是一个好主意。负面测试可帮助你确认资源不会产生意外的行为。例如，在部署虚拟机时，使用 Azure Bastion 安全连接到虚拟机是一种很好的做法。可向工作流添加负面测试，以验证你是否无法使用远程桌面连接或 SSH 直接连接到虚拟机。

重要

这些测试的目标不是为了验证 Bicep 是否已正确部署了资源。通过使用 Bicep，你假设它将部署你在 Bicep 文件中指定的资源。相反，目标是为了验证你定义的资源是否适用于你的情况并满足要求。

从 GitHub 工作流运行测试

可通过多种方式在工作流中运行测试。在本模块中，我们使用 Pester，它是一种开源工具，用于运行通过 PowerShell 编写的测试。 Pester 预安装在 GitHub 托管的运行程序上。无需执行任何特殊操作，即可在脚本步骤中使用它。

可选择使用不同的测试框架，甚至可在无测试工具的情况下选择运行测试。例如，另一个要考虑的测试工具是 PSRule for Azure，其中包括适用于 Azure 的预生成规则和测试。它可以对模板运行验证，还可以针对已部署的 Azure 资源运行测试。我们在总结中提供了指向 PSRule 的链接。

从工作流运行测试时，任何测试失败都应阻止工作流继续。在下一练习中，你将了解如何将工作流与基础结构冒烟测试结合使用。

测试结果将写入工作流日志。 GitHub 市场还包含非 Microsoft 操作，这些操作可显示和跟踪一段时间的测试结果。

在作业间传递数据

将工作流划分为多个作业时，每个作业都有各自的责任，有时需要在这些作业之间传递数据。例如，一个作业可能会创建另一个作业需要使用的 Azure 资源。若要能传递数据，则第二个作业需要知道创建的资源的名称。例如，冒烟测试作业需要访问部署了作业部署的资源。

你的 Bicep 文件会部署资源，因此它可以访问资源属性并将其发布为部署输出。通过 arm-deploy 操作运行 Bicep 部署时，此操作会在其步骤输出中存储这些 Bicep 部署输出。接下来，包含 arm-deploy 操作的作业现在可以将这些步骤输出作为作业输出发布。作业引用步骤的 id 属性，我们将其设置为 deploy：

deploy:
  runs-on: ubuntu-latest
  environment: Website
  needs: preview
  outputs:
    appServiceAppHostName: ${{ steps.deploy.outputs.appServiceAppHostName }}
  steps:
  - uses: actions/checkout@v3
  - 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
    id: deploy
    name: Deploy website
    with:
      deploymentName: ${{ github.run_number }}
      resourceGroupName: ${{ env.AZURE_RESOURCEGROUP_NAME }}
      template: ./deploy/main.bicep
      parameters: environmentType=${{ env.ENVIRONMENT_TYPE }}

可以在任何后续作业中访问某一作业的输出，只要它依赖于生成输出的作业：

smoke-test:
  runs-on: ubuntu-latest
  needs: deploy
  steps:
  - uses: actions/checkout@v3
  - run: |
      $container = New-PesterContainer `
        -Path 'deploy/Website.Tests.ps1' `
        -Data @{ HostName = '${{needs.deploy.outputs.appServiceAppHostName}}' }
      Invoke-Pester `
        -Container $container `
        -CI
    name: Run smoke tests
    shell: pwsh

还可使用特殊语法传递工作流脚本的输出。在摘要中，我们提供了更多信息的链接。

其他测试类型

功能测试和集成测试通常用于验证部署的资源是否按预期表现。例如，集成测试可能会连接到你的网站并提交测试事务，然后等待确认事务成功完成。通过使用集成测试，可测试你团队生成的解决方案以及它运行的基础结构。在以后的模块中，你将了解如何将这些类型的测试添加到工作流中。

还可从部署工作流运行其他类型的测试，包括性能测试和安全渗透测试。这些测试不在本模块的范围内，但它们可以向自动化部署过程增加价值。

回滚或前滚

假设工作流成功部署了资源，但测试失败了。那么应该怎么做呢？

在本模块的前面部分，你已了解通过 GitHub Actions 可创建在上一作业失败时运行的回滚作业。可使用此方法创建一个在测试作业报告显示意外结果时运行的回滚作业。如果你认为失败是由临时问题导致，且这个问题已得到解决，则还可以手动回滚更改，或重新运行整个工作流。

注意

向 Azure 资源管理器提交部署时，可请求资源管理器在部署失败时自动重新运行上一个成功的部署。为此，请在使用 Azure CLI 的 az deployment group create 命令提交部署时使用 --rollback-on-error 参数。

例如，可将回滚作业添加到工作流。当冒烟测试作业失败时，回滚作业将运行：

rollback: 
  runs-on: ubuntu-latest
  needs: smoke-test
  if: ${{ always() && needs.smoke-test.result == 'failure' }}
  steps:
  - run: |
      echo "Performing rollback steps..."

该作业取决于冒烟测试作业。它仅在冒烟测试失败时运行。默认情况下，每当上一个作业失败时，GitHub Actions 都会停止工作流。 if 条件包括用于替代此行为的 always() 检查。如果表达式中没有 always()，则每当前一个作业失败时，都将跳过回滚作业。

确定回滚作业应该执行的步骤通常具有挑战性。一般来说，Bicep 部署很复杂，回滚更改并不容易。如果部署包含其他组件，则回退尤其困难。

例如，假设工作流部署了一个 Bicep 文件来定义 Azure SQL 数据库，然后向该数据库添加了一些数据。部署回退时，是否应删除数据？是否应同时删除数据库？很难预测每次失败和每次回滚会对运行的环境产生怎样的影响。

出于此原因，许多组织都倾向于前滚，这意味着他们可以快速解决导致失败的原因，然后再次部署。通过构建高质量的自动化部署过程，并遵循你在这些学习路径中了解到的所有最佳做法，你将能够快速修复问题并重新部署 Bicep 文件，同时保持高质量。

提示