了解环境
使用部署工作流可自动执行部署过程中的步骤。 通常，需要在多个单独的环境中运行这些步骤。 在玩具公司，你需要在将更改部署到生产环境之前查看对代码所做的更改。
本单元将介绍 GitHub Actions 中的环境如何帮助你支持你自己的进程。
为什么有多个环境？
部署过程会对 Azure 资源（包括使用中的资源）进行更改。 更改资源也许会带来一些风险，因为部署的更改可能不会按预期工作。 你甚至可能会发现这些更改中断了当前的设置。
为了最大程度地降低出现问题的风险，在将更改部署到生产环境之前，最好以安全的方式尝试更改。 通过将更改部署到非生产环境，可最大限度地降低风险。
许多组织设置多个非生产环境，在将更改发布到生产环境前将其逐步部署到这些非生产环境。 每个非生产环境都有特定的用途，通常会有特定的质量关卡，必须通过这些关卡才能进入下一个环境。 如果出现问题（如测试失败）时，部署便会停止。 随着逐一部署到每个环境，你对更改也会越来越有信心。
常见环境包括：
开发：开发人员通常使用开发环境来尝试更改并快速迭代他们的工作。
开发环境通常具有最低限度的控制，以便团队成员可以轻松尝试想法。 你可以使用开发环境来测试资源的特定配置设置，或者了解如何以安全的方式使用后端数据库设置新网站。 其中有许多更改和尝试可能不会在部署过程中有进一步进展，因为你会不断取缔不成功的创意。
在某些团队中，你甚至可以为每个团队成员设置单独的开发环境，以便他们在开发新功能时不会妨碍彼此。
开发环境有时也称为沙盒环境。
测试：测试环境旨在针对更改运行手动或自动测试。
测试环境可用于持续集成过程。 将更改部署到测试环境后，可以针对它运行自动测试。 如果已通过所有自动测试，则更改可以安全地合并到项目的主分支中。 自动测试通常会检查核心系统功能，以及新部署资源中的策略违规等内容。
还可以为特定类型的测试（如性能和安全测试）创建专用测试环境。
集成：集成环境可帮助你测试与其他系统的任何集成点。
你可以在集成环境中模拟端到端事务。 这些测试通常会自动运行，但许多组织也会针对此环境执行手动测试。
集成环境有时也称为系统集成测试 (SIT) 环境。
用户验收测试：用户验收测试 (UAT) 环境用于手动验证，通常由业务利益干系人而不是开发人员使用。 在手动验证中，相关人员会检查解决方案并验证其行为是否符合预期以及是否满足了必要的业务要求。 然后该名人员批准更改，以便部署可以继续。
预生产：预生产环境通常是生产环境的镜像，具有相同的资源 SKU 和配置。 它用作最终检查，以验证生产部署在应用更改期间和之后的行为方式。 该环境还可用于验证是否能预料到生产部署期间的任何停机事件。
预生产环境有时也称为过渡环境。
生产：生产环境是应用程序的最终用户所使用的环境。 这是你想要保护并尽可能保持正常运行的实时环境。
在某些组织中，你可能有多个生产环境。 例如，你可能在不同的地理区域拥有生产环境或为不同的客户组提供服务。
演示：你的团队还可能创建演示环境以向最终用户展示应用程序、用于培训或供销售团队向潜在客户展示某些功能。 甚至可以有多个演示环境，用于不同的用途。 演示环境通常是生产环境的精简副本，带有虚假的客户数据。
组织中的环境
你可能会看到这些环境的变化。 某些组织仅使用几个环境，有些组织则使用更多环境。 所使用环境的数量和类型取决于要部署的解决方案、构建解决方案的团队规模以及工作负载的重要性。
有时，单个环境会扮演前面列出的多个环境的角色。 其他时候，你可能会有一个复杂的工作流，会部署到多个环境，有些并行部署，有些按顺序部署。 某些组织甚至会在不再使用环境时自动删除或撤销环境，然后在将来需要时重新部署。
无论组织选择哪些环境，其目标都是通过在部署工作流中推进更改来增强你对更改的信心。 当更改不符合质量要求时，你希望能够停止将更改部署到链中的任何后续环境中。
在玩具公司，你决定从一组基本的网站环境着手。 除了生产环境之外，你还将创建一个名为“测试”的非生产环境：
你将更新工作流，将 Bicep 代码部署到测试环境，并针对它运行一些基本测试。 如果该操作成功，则你可以部署到生产环境。
工作流环境
GitHub Actions 也有环境的概念。 你创建一个 GitHub Actions 环境来表示你在 Azure 中拥有的环境。 在 YAML 文件中定义工作流时，可以将作业链接到特定环境。 通过使用环境，可获取工作流中的一些附加功能。
保护规则
GitHub Actions 中的环境可以配置保护规则。 每次在工作流中的作业中使用环境时，GitHub Actions 将确保在作业开始运行之前满足这些规则。
例如，可以在生产环境上配置手动评审。 在生产部署开始之前，指定的审批者将收到通知。 该人员可以在部署开始之前手动验证你的策略和过程是否得到满足。 例如，审批者可能会在批准部署之前检查预生产环境中的一切是否按预期工作。
此外，可以运行自动检查来确认更改来自哪个分支。 如果更改不在主分支上，可以配置 GitHub以防止将其部署到生产环境。
机密
通过 GitHub Actions 可以存储只能在特定环境中使用的机密。 本模块后面部分将详细介绍机密管理。
部署历史记录
GitHub Actions 跟踪部署到环境的历史记录。 通过该历史记录可轻松跟踪环境中一段时间内发生的状况。 它甚至允许跟踪存储库中的提交部署。 如果遇到部署问题并需要确定导致问题的更改，则此功能非常有用。
创建环境
可以使用 GitHub Web 界面创建环境。
当工作流引用不存在的环境时，GitHub Actions 会自动为你创建它。 此功能会影响 GitHub 存储库的安全性，因为新环境不会配置任何保护规则。 最好通过 Web 界面自己创建环境，以便可以完全控制其安全性。
将部署作业链接到环境
在部署工作流定义中，可以使用 environment 属性来引用环境：
jobs:
deploy:
environment: Test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
在此示例中，名为 deploy 的作业链接到 Test 环境。
环境和与 Azure 的连接
使用多个环境时，应使每个环境独立于其他环境。 例如，开发环境的网站不应能够访问生产环境中的数据库。
相同的原则也适用于部署工作流。 应为每个环境创建单独的工作负载标识。 遵循此做法可新增一层保护，确保非生产部署不会影响生产环境。
应为工作负载标识分配特定权限，以便仅将其部署到该环境使用的订阅和资源组：
重要
为计划部署到的每个环境使用单独的工作负载标识。 向工作负载标识授予部署到其环境所需的最低权限，且不授予其他任何权限。
在 Azure 中分离环境也是一个好办法。 至少应为每个环境创建单独的资源组。 在许多情况下，最好为每个环境创建单独的 Azure 订阅。 然后，可以在每个环境的订阅中创建多个资源组。
应用 Azure 角色分配，以便用户和工作负载标识只能访问他们需要访问的环境。 而且要注意将生产环境的访问权限仅授予一小部分人员以及该环境的部署工作负载标识。
环境的联合凭据
当工作负载标识从部署工作流连接到 Azure 时，它使用联合凭据安全地对自身进行身份验证，不需要任何机密或密钥。 在此学习路径的前一个模块中，联合凭据在从 Git 存储库的主分支部署时，授予了对部署工作流的访问权限。
当你部署到工作流中的环境时，需要使用范围限定为环境的联合凭据。
在本模块中，你的工作流包括一些作业，其中许多都连接并部署到 Azure。 有些作业使用环境，有些则不使用。 因此，你需要为每个工作负载标识创建两个联合凭据：一个范围限定为环境，一个范围限定为主分支。