简介

使用 Bicep 代码时，所有更改都必须经过评审和测试，这一点很重要。即使你的部署工作流和流程旨在检测 bug 或问题，但尽早发现并修复任何问题会比较省时。拉取请求为评审代码更改提供了机会。评审 Azure 部署时，建议的做法是，不仅要验证代码更改，还要验证更改是否已成功部署并按预期运行。

在此模块中，你将了解如何将自动检查添加到拉取请求评审过程。你将了解如何在拉取请求中将 Bicep 代码合并或部署到实际环境之前验证对它的更改。

你还将了解如何将更改自动部署到临时环境。在该环境中，协作者和审阅者可以在代码更改获得批准并合并到存储库的主分支之前对其进行测试。

示例方案

假设你是一家玩具公司的 Azure 管理员。你一直在与网站团队携手共建可为你的网站部署和配置 Azure 资源的 Bicep 代码。

你的团队正在不断发展，因此，控制每个人所做的所有更改也越来越困难。你最近开始使用拉取请求，以确保在将更改合并到项目的 GitHub 存储库的主分支之前评审它。每个审阅者都可以验证拉取请求中的 Bicep 代码更改，许多审阅者甚至会将更改部署到临时环境中，以便他们可以测试这些更改。

你的同事告诉你，当前的手动评审过程会比较繁琐且耗时。重要的是要确保团队中的每个人都可以轻松进行拉取请求评审，因此，你决定在拉取请求中自动执行某些评审过程。

你需要对网站的配置进行一些更改，因此这是建立和测试新过程的好机会。

在此模块中，你将了解如何对每个拉取请求运行自动检查和测试，以在 Bicep 代码更改中生成置信度。

使用 Bicep Linter 将拉取请求工作流配置为根据推荐的做法来扫描 Bicep 代码。为每个拉取请求配置临时环境的创建，这可用于评审 Azure 环境的更改，并在合并或关闭拉取请求时自动删除环境。

完成此模块后，你将能够向 Bicep 代码的 GitHub 拉取请求添加自动检查和验证。