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