部署临时环境以进行评审
对 Bicep 代码进行 Lint 分析可指示 Azure 部署是否可能成功。 你还将发现，在某处实际部署 Bicep 代码也很有用，这样你可以查看环境在合并拉取请求并完成部署后的样子。
本单元将介绍如何从拉取请求内将代码部署到临时环境。
为什么要从拉取请求中部署代码？
当你要评审包含 Bicep 代码的拉取请求时，建议的做法是将 Bicep 代码部署到实时 Azure 环境。 通过执行此操作，有助于建立更改在到达生产环境时可正常运行的信心。 如果有问题，你会希望尽快发现它。 拉取请求为你提供了一个发现和突出显示问题的绝佳机会，因为你可以立即从审阅者处获得反馈。
现在，你已习惯于先将更改部署到一个或多个非生产环境（如测试、QA 和暂存），然后再将其部署到生产环境这种思路。 在许多组织中，这些环境会长期存在，这意味着推出更改时会更新这些环境，通常不会删除它们。
相比之下，临时环境是动态创建的环境，并且可以在它无用时将其删除。 临时环境只会存在很短的时间（例如，时间刚好够评审更改）。
为拉取请求部署环境时，临时环境是一个不错的选择，因为你可能一次会打开多个不同的拉取请求，这代表不同类型的更改。 如果打开了多个拉取请求，则共享长期非生产环境意味着一次只能预览一个更改。
创建临时环境
由于你已习惯构建 Azure 基础结构即代码，并且已投资构建 Bicep 文件来部署资源，因此可以重复使用这些相同的资产来部署临时环境。 如果需要，甚至可以一次部署多个临时环境。 你只需确保部署已充分参数化和通用化，以便可以轻松创建独立环境。 例如，需要确保为某些 Azure 资源提供全局唯一的名称，这些名称不能与任何其他临时或长期环境中的资源名称相同。
临时环境具有许多优势：
- 可以在不影响其他生产或非生产工作负载的独立环境中安全地测试新特性和功能。
- 可以在你自己的分支中显示更改，使你可以轻松地向同事展示工作，或者为审阅者提供访问权限。
- 可以让多个团队成员同时测试单独的更改，即使这些更改不兼容。
- 由于临时环境涉及定期运行 Bicep 文件，因此它们可帮助你持续测试 Bicep 代码和其他脚本的准确性和完整性。 因此，你可以更加确信代码将在生产环境中完美运行。
在此模块中，你将创建临时环境，以帮助你建立对拉取请求中更改的置信度。 在批准和合并拉取请求之前，评审拉取请求的任何人都可以访问临时环境，包括任何新增内容和更新内容。
部署
使用临时环境时，最好为你团队创建的每个拉取请求创建各自的 Azure 资源组。 如果一个作者打开了两个不同的拉取请求，则每个拉取请求都拥有其自己的临时环境。 这有助于将每个更改与其他更改分开，并避免混淆或意外覆盖资源。
若要使用此方法，拉取请求验证工作流需要动态创建资源组。 资源组需要唯一的名称，并且你还需要能够轻松找到资源组以测试资源，并在拉取请求关闭时将其删除。 若要有效地处理资源组名称，可以在资源组名称内使用拉取请求编号。 在下一练习中，你将了解如何执行此操作。
当需要删除临时环境时，工作流可以轻松查找和删除整个资源组。 临时环境中使用的所有资源都将同时删除。
权限
创建资源组需要订阅级权限，并且通常需要将“参与者”角色分配给工作流的工作负载标识。
建议的做法是为临时环境使用专用 Azure 订阅。 通过遵循此方法，你可以向工作流的工作负载标识和团队成员授予访问权限，而不会意外提供对其他环境的访问权限。
重要
订阅范围的参与者功能强大，因此你需要确保对工作流的工作负载标识及其可部署的更改有足够的治理能力。 通过将专用订阅用于临时环境，可以降低其他环境的风险。
工作流标识
部署工作流使用工作负载标识和联合凭据向 Azure 进行身份验证。 使用拉取请求验证工作流时，需要将联合凭据配置为使用拉取请求。
在本模块的上个练习中，你运行了一个命令来创建联合凭据。 策略字符串如下所示：
repo:my-github-user/my-repo:pull_request
字符串末尾附近的 pull_request 指定联合凭据适用于拉取请求验证工作流。
成本管理
动态创建临时环境时，Azure 成本可能会增加。 如果你的团队打开了大量拉取请求，你可以将大量昂贵的资源部署到 Azure。
提示
如果你的团队快速关闭拉取请求，则不必太担心成本增加，因为关闭相应的拉取请求时，会删除临时环境。
通过使用专用 Azure 订阅，还可以轻松监视临时环境的成本。 此外，还可以应用限制临时资源的 SKU 的订阅范围策略，这有助于避免成本超支。
另外，Azure 还提供了许多方法来帮助你控制临时环境的成本，包括：
- 可使用 Microsoft 成本管理为订阅设置预算。 预算会触发通知，以便你的团队知道成本即将达到指定的阈值。
- 许多 Azure 资源类型为非生产工作负载提供了更便宜甚至免费的层。 考虑是否可以使用这些定价层和 SKU。
- Azure 开发/测试定价可供部分客户用于其非生产订阅。
- 资源标记可帮助你识别与每个临时环境关联的资源，并计算每个临时环境的成本。
- 你可以创建自动化脚本，以在定义的一段时间段后，甚至在每天晚上下班后删除临时资源。
还可以考虑在临时环境之间共享某些资源。 例如，Bicep 代码可能会定义许多资源，其中一些资源成本高，或者预配需要花费很长时间。 你可以为所有拉取请求创建一个长期的共享资源组，以共享昂贵的资源，并针对其他资源创建单独的临时资源组。 但是，此方法使得管理临时环境和使临时环境分离开足够的距离以促进评审过程会变得十分困难且容易出错。 除非临时环境的成本过高，否则最好避免使用此方法。