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

  • 项目

Azure DevOps Services | Azure DevOps Server 2020

环境是一个 资源 集合，可以使用管道中的部署进行目标。 环境名称的典型示例包括开发、测试、QA、过渡和生产。

环境具有以下优势。

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

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

创建环境

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

  2. 选择“Pipelines>Environments>创建环境”。

    Environments

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

    Screenshot of creating a new environment.

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

提示

可以创建一个空环境，并从部署作业引用它。 这样，便可以根据环境记录部署历史记录。

从部署作业定位环境

部署作业是按顺序运行的步骤集合。 部署作业可用于针对整个环境 (资源组) ，如以下 YAML 代码片段所示。

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

从部署作业定位环境中的特定资源

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

environment: '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

运行详细信息中的环境

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

Environments in run details

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

审批

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

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

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

部署历史记录

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

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

    Screenshot of deployment history listing.

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

    Screenshot of commits under deployment history.

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

    Screenshot of work items under deployment history.

安全性

用户权限

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

  1. 转到要授权的特定 环境 。
  2. 选择“安全性”>以查看设置。
  3. 选择 “用户权限>+添加>用户或组”，然后选择合适的角色。
角色 说明
创建者 全局角色，可从环境中心安全选项获取。 此角色的成员可以在项目中创建环境。 默认情况下，参与者将添加为成员。 当环境尚不存在时触发 YAML 管道所必需的。
读取者 此角色的成员可以查看环境。
用户 创建或编辑 YAML 管道时，此角色的成员可以使用环境。
管理员 除了使用环境，此角色的成员还可以管理环境所有其他角色的成员身份。 默认情况下，创建者将添加为成员。

管道权限

使用管道权限来授权所有或所选管道以部署到环境。

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

后续步骤

定义审批和检查

常见问题解答

问：尝试创建环境时，为何会收到错误消息？

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

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

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

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

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

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

  • 如果使用 运行时参数 来创建环境，它将失败，因为这些参数在运行时扩展。 环境创建在编译时发生，因此必须使用 变量 来创建环境。

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