创建环境并以该环境为目标

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

环境是一个资源集合，可以通过管道中的部署来定位这些资源。 环境名称的典型示例包括“开发”、“测试”、“QA”、“过渡”和“生产”。 Azure DevOps 环境表示管道在其中部署软件的逻辑目标。

Azure DevOps 环境在经典管道中不可用。 对于经典管道，部署组提供类似的功能。

环境具有如下优点。

好处	说明
部署历史记录	将记录到环境及其资源的部署的管道名称和运行详细信息。 在面向同一环境或资源的多个管道的上下文中，环境的部署历史记录可用于识别更改源。
提交和工作项的可追溯性	查看管道运行中面向环境的作业。 还可以查看新部署到环境的提交和工作项。 可跟踪性还允许跟踪代码更改（提交）或功能/错误修复（工作项）是否到达环境。
诊断资源健康状况	验证应用程序是否在其所需状态下运行。
安全性	通过指定允许哪些用户和管道以环境为目标来保护环境。

虽然环境是一组资源，但资源自身表示实际的部署目标。 目前支持 Kubernetes 资源和虚拟机资源类型。

如果你创作 YAML 管道时引用了不存在的环境，则在执行操作的用户身份已知且可以被分配权限时，Azure Pipelines 会自动创建环境。 若 Azure Pipelines 没有有关用户创建环境的信息（例如：外部代码编辑器中的 YAML 更新），则在不存在环境的情况下，管道将失败。

先决条件

• 需要具有环境创建者角色才能添加环境。

创建环境

1. 登录到你的组织：https://dev.azure.com/{yourorganization}，并选择你的项目。

2. 选择“管道”>“环境”>“创建环境”。

   

3. 输入环境信息，然后选择“创建”。 稍后可将资源添加到现有环境。

   

也可以使用管道创建并部署到环境。 有关详细信息，请参阅操作指南。

提示

可以创建一个空环境，并从部署作业中引用它。 这样就可以记录针对环境的部署历史记录。

从部署作业中，将某个环境作为目标

部署作业是按顺序运行的步骤的集合。 部署作业可用于面向整个环境（资源组），如以下 YAML 代码片段所示。 管道将在 myVM 计算机上运行，因为指定了资源名称。

- stage: deploy
  jobs:
  - deployment: DeployWeb
    displayName: deploy Web App
    pool:
      vmImage: 'Ubuntu-latest'
    # creates an environment if it doesn't exist
    environment: 
      name: 'smarthotel-dev'
      resourceName: myVM
      resourceType: virtualMachine
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo Hello world

从部署作业，将环境中的特定资源作为目标

可以将部署目标的范围限定为环境中的特定资源。 然后，可以在环境中记录特定资源上的部署历史记录。 部署作业的步骤自动从部署作业的目标资源继承服务连接详细信息。

environment: 
  name: 'smarthotel-dev.bookings'
strategy: 
 runOnce:
   deploy:
     steps:
     - task: KubernetesManifest@0
       displayName: Deploy to Kubernetes cluster
       inputs:
         action: deploy
         namespace: $(k8sNamespace)
         manifests: $(System.ArtifactsDirectory)/manifests/*
         imagePullSecrets: $(imagePullSecret)
         containers: $(containerRegistry)/$(imageRepository):$(tag)
         # value for kubernetesServiceConnection input automatically passed down to task by environment.resource input

运行中的环境详细信息

在管道运行详细信息的“环境”选项卡下，可以找到以特定管道运行的部署作业作为目标的所有环境。

如果使用 AKS 专用群集，则“环境”选项卡不可用。

审批

手动控制应使用批准检查运行阶段的时间。 使用批准检查来控制部署到生产环境的部署。 资源所有者可以进行一些检查来控制管道中的阶段何时使用资源。 用户作为资源（如环境）的所有者，可以定义在使用该资源的阶段开始之前必须满足的批准和检查。

我们支持对环境进行手动批准检查。 有关详细信息，请参阅审批。

创建者、管理员和用户角色可以管理批准和检查。 读取者角色无法管理批准和检查。

部署历史记录

环境中的部署历史记录视图具有以下优势。

• 从面向特定环境的所有管道中查看作业。 例如，两个微服务（每个都有其自己的管道）部署到同一环境。 部署历史记录列表有助于识别影响此环境的所有管道，还有助于可视化每个管道的部署顺序。

  

• 向下钻取作业详细信息，查看部署到环境的提交和工作项的列表。 提交和工作项的列表是不同部署之间新增的项。 你的第一个列表包括所有提交，以下列表将仅包含更改。 如果多个提交绑定到同一拉取请求，你将在工作项和更改选项卡上看到多个结果。

  

• 如果多个工作项绑定到同一个拉取请求，你将在“工作项”选项卡上看到多个结果。

  

安全性

用户权限

控制谁可以使用用户权限创建、查看、使用和管理环境。 有四个角色 - 创建者（范围：所有环境）、读者、用户和管理员。 在特定环境的用户权限面板中，可以设置继承的权限，并且可以覆盖每个环境的角色。

1. 转到要授权的特定环境。
2. 选择>“安全性”以查看设置。
3. 选择“用户权限”>“添加+”>“用户或组”，然后选择合适的角色。

角色	说明
创建者	全局角色，可从环境中心安全选项获取。 此角色的成员可以在项目中创建环境。 默认情况下，参与者会被添加为成员。 在不存在环境的情况下触发 YAML 管道所必需。
读者	此角色的成员可以查看环境。
用户	此角色的成员可以在创建或编辑 YAML 管道时使用环境。
管理员	此角色的成员可以管理权限、创建、管理、查看和使用环境。 在特定环境下会默认将创建者添加为管理员。 管理员还可以向所有管道开放环境的访问权限。

管道权限

使用管道权限授权要部署到环境中的所有或选定管道。

• 要移除对环境或资源的“开放访问权限”，请在“管道权限”中选择“限制权限”。
• 要允许特定管道部署到环境或特定资源，请选择 + 并从管道列表中选择。

后续步骤

定义审批和检查

常见问题解答

问：当我尝试创建环境时，为什么会收到错误消息？

答：如果你看到消息“访问被拒绝：{User} 需要创建权限才能执行操作”，请检查组织级别权限。 请转到“组织设置”>“用户”并检查你是否具有利益干系人角色。 利益干系人角色无法创建环境。 更改访问级别，然后检查以查看是否可以创建环境。 有关详细信息，请参阅用户和权限管理常见问题解答。

问：为什么我收到错误“作业 XXXX：找不到环境 XXXX。 该环境不存在或未授权使用”？

答：以下是失败的一些可能原因：

• 在创作 YAML 管道并引用 YAML 文件中不存在的环境时，Azure Pipelines 在某些情况下会自动创建环境：

  • 在 Azure Pipelines Web 体验中使用 YAML 管道创建向导，并引用尚未创建的环境。
  • 使用 Azure Pipelines Web 编辑器更新 YAML 文件，并在添加对不存在的环境的引用后保存管道。

• 在以下流中，Azure Pipelines 没有关于创建环境的用户的信息：使用其他外部代码编辑器更新 YAML 文件，添加对不存在的环境的引用，然后触发手动或持续集成管道。 在这种情况下，Azure Pipelines 并不了解用户。 以前，我们通过将所有项目参与者添加到环境的管理员角色来处理这种情况。 然后，项目的任何成员都可以更改这些权限，并阻止其他人访问环境。

• 可以使用变量创建环境或使用 templateContext 将属性传递给模板。 运行时参数在创建环境时不起作用，因为它们是在运行时展开的。

• 处于利益干系人访问级别的用户无法创建环境，因为利益干系人无权访问存储库。

相关文章

• 定义变量
• 在 YAML 中定义资源