部署后测试资源
通过验证和预览 Bicep 部署，你已对 Bicep 文件将成功部署充满信心。 但部署并不是故事的全部。 部署完成后，检查部署是否按预期运行也会很有用。
在本单元中，你将了解部署完成后可运行的测试。 你还将了解在情况未达到预期时如何回退部署。
运行冒烟测试和负面测试
在 Bicep 文件中定义资源时，你的目标不仅仅是在 Azure 中创建资源。 还要在满足组织要求的同时向组织传递价值。 验证和预览 Bicep 文件时，可以确信资源定义有效，但并不确定资源是否会执行所需的操作。
例如，假设使用 Bicep 部署管道部署新的 Azure SQL 逻辑服务器。 服务器的 Bicep 定义是有效的，因此它通过了 Linter 和预检验证阶段。 What-if 命令显示将创建一个服务器，这正是你所期望的。 部署也成功完成。 但在部署过程结束时，你可能仍然没有一个现成可用的数据库服务器。 原因可能包括：
- 尚未配置防火墙规则以允许网络流量到达服务器。
- 你在不应在服务器上启用 Microsoft Entra 身份验证时执行了此操作，或在应启用时未执行。
即使只是在部署基本的 Bicep 文件，也值得考虑如何验证部署的资源是否确实有效并满足要求。 以下是有关如何应用此原则的示例：
- 部署网站时，尝试从管道访问 Web 应用程序。 验证管道是否成功连接到网站并收到有效的响应代码。
- 在部署内容交付网络 (CDN) 时，请尝试通过 CDN 连接到资源。 验证管道是否成功连接到 CDN 并收到有效的响应代码。
这些测试有时称为“基础结构冒烟测试”。 冒烟测试是一种简单的测试形式，旨在发现部署中的主要问题。
注意
某些 Azure 资源并不能通过 Microsoft 托管管道代理轻松访问。 如果需要通过专用网络访问资源，可能需要考虑使用自托管代理来运行版本验收测试阶段。
执行负面测试也是一个好主意。 负面测试可帮助你确认资源不会产生意外的行为。 例如，在部署虚拟机时，使用 Azure Bastion 安全连接到虚拟机是一种很好的做法。 可以向管道添加负面测试，验证确保你无法使用远程桌面连接或 SSH 直接连接到虚拟机。
重要
这些测试并不是为了验证 Bicep 是否已正确部署了资源。 通过使用 Bicep，你假设它将部署你在 Bicep 文件中指定的资源。 相反，目标是为了验证你定义的资源是否适用于你的情况并满足要求。
从 Azure Pipelines 运行测试
可以通过多种方式在管道中运行测试。 在本模块中，我们使用 Pester，它是一种开源工具，用于运行通过 PowerShell 编写的测试。 可选择使用其他测试框架，甚至可选择在无测试工具的情况下运行测试。 例如，另一个要考虑的测试工具是 PSRule for Azure，其中包括适用于 Azure 的预生成规则和测试。 它可以对模板运行验证，还可以针对已部署的 Azure 资源运行测试。 我们在总结中提供了指向 PSRule 的链接。
使用受支持的测试框架时，Azure Pipelines 会了解每个测试的结果。 它在管道运行信息旁边显示测试结果，并跟踪一段时间内每个测试的历史记录。 在下一练习中，你将了解如何将 Azure Pipelines 与基础结构冒烟测试结合使用。
在步骤和阶段之间传递数据
将管道划分为多个阶段时，每个阶段都有各自的责任，有时需要在这些阶段之间传递数据。 例如，一个阶段可能会创建另一个阶段需要使用的 Azure 资源。 为了能够传递数据，第二个阶段需要知道创建的资源的名称。 例如，冒烟测试阶段需要访问部署阶段部署的资源。
你的 Bicep 文件会部署资源，因此它可以访问资源属性并将其发布为部署输出。 可以在管道中访问部署输出。 在 Azure Pipelines 中，发布变量有一种特殊的语法，使它们可跨各个阶段使用。
首先，需要为管道阶段发布输出变量。 若要输出该变量，请将 Azure Pipelines 能够理解的特殊格式的字符串写入管道日志。 在以下示例中，名为 myVariable 的变量已设置为值 myValue：
echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"
Azure Pipelines 从管道日志中读取和解释字符串，并使变量的值可用作输出。 可以将此值与更多脚本结合使用，以将 Bicep 部署输出的值发布为管道阶段输出变量。 在下一练习中，你将了解如何处理此脚本。
其次，需要使变量可用于冒烟测试阶段的作业。 为作业定义一个变量，并使用另一个特殊格式的 YAML 字符串：
- stage: SmokeTest
jobs:
- job: SmokeTest
variables:
myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]
现在，通过使用语法 $(myVariable)，冒烟测试作业中的任何步骤都可以像访问任何其他变量一样访问 myVariable 值。 下一练习中将使用一个变量。
其他测试类型
功能测试和集成测试通常用于验证部署的资源是否按预期表现。 例如，集成测试可能会连接到你的网站并提交测试事务，然后等待确认事务成功完成。 通过使用集成测试，可测试你的团队生成的解决方案以及它所依托的基础结构。 在以后的模块中，你将了解如何将这些类型的测试添加到管道中。
还可以从部署管道运行其他类型的测试，包括性能测试和安全渗透测试。 这些测试不在本模块的范围内，但它们可以向自动化部署过程增加价值。
回滚或前滚
假设管道成功部署了资源，但测试失败。 那么应该怎么做呢？
在本模块的前面部分，你已了解到通过 Azure Pipelines 可创建在前一阶段失败时运行的回退阶段。 可以使用此方法创建一个在测试阶段报告意外结果时执行的回退阶段。 如果你认为失败是由临时问题导致，且此问题已得到解决，则还可手动回滚更改，或者重新运行整个管道。
注意
向 Azure 资源管理器提交部署时，可请求资源管理器在部署失败时自动重新运行上一个成功的部署。 为此，需要使用 Azure CLI 步骤部署文件，并在使用 az deployment group create 命令提交部署时添加 --rollback-on-error 参数。
确定回退阶段应执行的步骤通常具有挑战性。 一般来说，Bicep 部署很复杂，回滚更改并不容易。 如果部署包含其他组件，则回退尤其困难。
例如，假设你的管道部署了一个 Bicep 文件来定义 Azure SQL 数据库，然后向该数据库添加了一些数据。 部署回退时，是否应删除数据？ 是否应同时删除数据库？ 很难预测每次失败和每次回滚会对运行的环境产生怎样的影响。
出于此原因，许多组织都倾向于前滚，这意味着他们可以快速解决导致失败的原因，然后再次部署。 通过构建高质量的自动化部署过程，并遵循你在这些学习路径中了解到的所有最佳做法，你将能够快速修复问题并重新部署 Bicep 文件，同时保持高质量。
提示
DevOps 思维模式的原则之一是从错误中学习。 如果必须回滚部署，请仔细考虑错误发生的原因，并在部署开始之前添加自动测试，以在将来发生相同问题时进行检测。