Azure Pipelines - Sprint 160 更新

功能

• 多阶段管道用户体验
• 在 Kubernetes 环境中协调 Canary 部署策略
• YAML 管道的审批策略
• 作为第一类管道资源的 ACR
• 管道资源元数据作为预定义变量
• 管道和 ACR 资源的可追溯性
• 简化 YAML 管道中的资源授权
• 通过限制访问令牌的范围提高管道安全性
• 评估项目检查
• 自动测试错误消息中的 Markdown 支持
• 诊断 YAML 中的 Cron 调度
• ARM 模板部署任务的更新
• 服务连接的项目级别安全性
• Ubuntu 18.04 软件库
• KubernetesManifest 任务中基于服务对等网格接口的 canary 部署
• 环境中的 ReviewApp

多阶段管道用户体验

我们一直在努力更新和优化管道管理方面的用户体验。 这些更新可实现管道体验的现代化，并与 Azure DevOps 体验的发展和优化保持一致。 此外，这些更新将经典的生成管道和多阶段 YAML 管道合并为单个体验。 例如，新用户体验中包括以下功能：查看和管理多个阶段流程，批准管道运行的请求，在管道运行时能够向上滚动查看所有日志，以及管道每个分支的运行状况。

感谢所有尝试过新体验的人。 如果尚未尝试，可在预览功能中启用 多阶段管道 。 若要了解有关多阶段管道的详细信息，请参阅此处的文档。

由于你的反馈，我们在最近两次更新中解决了以下内容。

1. 文件夹视图的易发现性。
2. 日志视图中的跳转性。
3. 即使运行正在进行中，也可以轻松显示以前和当前任务的日志。
4. 在查看日志时，方便地在任务之间导航。

注意

在下一个更新中，我们计划默认为每个人启用此功能。 你仍可以选择退出预览版体验。 几周后，此功能将正式发布。

在 Kubernetes 环境中协调 Canary 部署策略

持续交付应用程序更新的一个关键优势是能够快速将特定微服务的更新推送到生产中。 这使你能够快速响应业务需求的变化。 环境 被引入为一级概念，能够协调部署策略并促进零停机发布。 以前，我们支持 runOnce 策略，它按顺序执行一次所有步骤。 借助多阶段管道中对 Canary 策略的支持，你现在可以通过将更改缓慢推广到一小部分来降低风险。 随着自己对新版本的信心越来越大，你可以开始将其部署到基础结构中的更多服务器，并将更多用户路由到该版本。

jobs:
- deployment:
  environment: musicCarnivalProd
  pool:
    name: musicCarnivalProdPool 
  strategy:                 
    canary:     
      increments: [10,20] 
      preDeploy:                                    
        steps:          
        - script: initialize, cleanup....  
      deploy:            
        steps:
        - script: echo deploy updates...
        - task: KubernetesManifest@0
          inputs:
            action: $(strategy.action)      
            namespace: 'default'
            strategy: $(strategy.name)
            percentage: $(strategy.increment)
            manifests: 'manifest.yml'
      postRouteTraffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

Kubernetes 的 Canary 策略将首先对 10% 的 Pod 部署更改，然后对 20% 的 Pod 部署更改，同时在 postRouteTraffic 期间监视运行状况。 如果一切顺利，这个比例会提升到 100%。

YAML 管道的审批策略

在 YAML 管道中，我们遵循资源所有者控制的审批配置。 资源所有者对资源进行审批，并且所有使用该资源的管道都会在开始使用资源的阶段之前暂停审批。 基于 SOX 的应用程序所有者通常会限制部署请求者审批其自己的部署。

现在 ，可以使用高级审批选项 来配置审批策略，例如请求者不应批准、需要部分用户批准和审批超时。

作为第一类管道资源的 ACR

如果你需要使用发布到 ACR（Azure 容器注册表）的容器映像作为管道的一部分，并在发布新映像时触发管道，则可以使用 ACR 容器资源。

resources:
  containers:
  - container: MyACR  #container resource alias
    type: ACR
    azureSubscription: RMPM  #ARM service connection
    resourceGroup: contosoRG
    registry: contosodemo
    repository: alphaworkz
    trigger: 
      tags:
        include: 
        - production 

此外，ACR 映像元数据可以使用预定义的变量进行访问。 以下列表包括可用于在管道中定义 ACR 容器资源的 ACR 变量。

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

管道资源元数据作为预定义变量

我们为管道中的 YAML 管道资源添加了预定义的变量。 下面是可用的管道资源变量列表。

resources.pipeline.<Alias>.projectName 
resources.pipeline.<Alias>.projectID 
resources.pipeline.<Alias>.pipelineName 
resources.pipeline.<Alias>.pipelineID 
resources.pipeline.<Alias>.runName 
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch 
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider 
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

管道和 ACR 资源的可追溯性

当在管道中使用流水线和 ACR 容器资源时，我们确保完整的端到端可追溯性。 对于 YAML 管道消耗的每种资源，你都可以追溯到提交、工作项和工件。

在管道运行摘要视图中，你可以看到：

• 触发运行的资源版本。 现在，可以在完成另一个 Azure 管道运行后或将容器映像推送到 ACR 时触发当前管道。

  

• 管道使用的提交。 你还可以找到管道消耗的每个资源的提交明细。

  

• 与管道使用的每个资源关联的工作项。

• 可供运行使用的工件。

  

在环境的部署视图中，你可以查看部署到环境的每个资源的提交和工作项。

简化 YAML 管道中的资源授权

资源是指管道外部的管道所使用的任何东西。 必须先对资源进行授权，然后才能使用资源。 以前，在 YAML 管道中使用未经授权的资源时，会因为资源授权错误而失败。 你必须从失败运行的摘要页面授权资源。 此外，如果管道使用的变量引用了未经授权的资源，管道也会失败。

现在，可以更轻松地管理资源授权。 运行不会失败，而是会在消耗资源的阶段开始时等待对资源的权限。 资源所有者可以从安全页查看管道并授权资源。

通过限制访问令牌的范围提高管道安全性

在 Azure Pipelines 中运行的每个作业都将获得一个访问令牌。 任务和脚本使用该访问令牌回调到 Azure DevOps。 例如，我们使用访问令牌来获取源代码、上传日志、测试结果、项目或对 Azure DevOps 进行 REST 调用。 为每个作业都生成一个新的访问令牌，该令牌将在作业完成后过期。 通过此更新，我们添加了以下增强功能。

• 阻止令牌访问团队项目外部的资源

  直到现在，所有管道的默认范围均为团队项目集合。 你可以在经典构建管道中将范围更改为团队项目。 但你没有对经典发布或 YAML 管道的这种控制权。 通过此更新，我们引入了一个组织设置，以强制每个作业获取项目范围的令牌，无论管道中配置了什么。 我们还在项目级别添加了此设置。 现在，你创建的每个新项目和组织都会自动启用此设置。

  注意

  组织设置将替代项目设置。

  如果管道使用访问令牌访问团队项目外部的资源，在现有项目和组织中启用此设置可能会导致某些管道失败。 若要缓解管道故障，你可以显式授予项目生成服务帐户对所需资源的访问权限。 强烈建议启用这些安全设置。

• 删除访问令牌的某些权限

  默认情况下，我们向访问令牌授予大量权限，其中一个权限是 队列生成。 通过此更新，我们删除了对访问令牌的这一权限。 如果管道需要此权限，则可以根据你使用的令牌，将其显式授予项目生成服务帐户或项目集合生成服务帐户。

评估项目检查

现在可以定义一组策略，并添加策略评估作为对容器映像项目环境的检查。 当管道运行时，执行将在开始使用环境的某一阶段前暂停。 指定的策略将根据正在部署的映像的可用元数据进行评估。 策略成功时检查通过，如果检查失败，则将阶段标记为失败。

自动测试错误消息中的 Markdown 支持

现在，我们在自动测试的错误消息中支持 Markdown。 可以轻松设置测试运行和测试结果的错误消息的格式，以提高可读性，并轻松排查 Azure Pipelines 中的故障。 此处可以找到支持的 Markdown 语法。

YAML 中的诊断 Cron 计划

我们已看到使用 cron 语法在 YAML 管道中指定计划的情况正在稳步增加。 听取您的反馈时，我们了解到您很难确定 Azure Pipelines 是否正确处理了语法。 以前，你必须等待计划运行的实际时间来调试计划问题。 为了帮助你诊断分支/语法错误，我们添加了管道的新操作菜单。 “运行管道”菜单中的“计划运行”将让你预览管道即将进行的几个计划运行，以帮助你诊断 cron 调度中的错误。

ARM 模板部署任务的更新

以前，不会在 ARM 模板部署任务中筛选服务连接。 如果选择较小范围的服务连接来执行以较大范围作为目标的 ARM 模板部署，可能会导致部署失败。 现在，我们添加了服务连接的筛选功能，可根据所选择的部署范围筛去范围较小的服务连接。

服务连接的项目级别安全性

通过此更新，我们为服务连接添加了中心级安全性。 现在，你可以在针对所有服务连接的一个集中位置添加/删除用户、分配角色和管理访问权限。

Ubuntu 18.04 池

Azure Pipelines 现在支持在 Ubuntu 18.04 上运行作业。 我们更新了Microsoft托管的 Azure Pipelines 池，以包含 Ubuntu-18.04 映像。 现在，在 YAML 管道中引用 ubuntu-latest 池时，它将意味着 ubuntu-18.04 而不是 ubuntu-16.04。 你仍然可以显式使用 ubuntu-16.04 在作业中将 16.04 映像作为目标。

KubernetesManifest 任务中基于服务对等网格接口的 canary 部署

以前，在 KubernetesManifest 任务中指定 Canary 策略时，该任务会创建基线工作负载和金丝雀工作负载，其副本数量等于稳定工作负载副本数量的某个百分比。 这与在请求级别上按所需百分比拆分流量不完全相同。 为了解决此问题，我们向 KubernetesManifest 任务添加了对 基于服务网格接口 的 Canary 部署的支持。

服务网格接口的抽象允许与服务网格提供程序（如 Linkerd 和 Istio）进行即插即用配置。 现在，KubernetesManifest 任务消除了在部署策略的生命周期中将 SMI 的 TrafficSplit 对象映射到稳定、基线和 Canary 服务的繁重工作。 由于百分比流量分割是根据服务网格平面中的请求进行控制的，因此稳定、基线和 Canary 之间所需的流量分配比例更加准确。

以下是以滚动方式执行基于 SMI 的 Canary 部署的示例。

- deployment: Deployment
    displayName: Deployment
    pool:
      vmImage: $(vmImage)
    environment: ignite.smi
    strategy:
      canary:
        increments: [25, 50]
        preDeploy:
          steps:
          - task: KubernetesManifest@0
            displayName: Create/update secret
            inputs:
              action: createSecret
              namespace: smi
              secretName: $(secretName)
              dockerRegistryEndpoint: $(dockerRegistryServiceConnection)
        deploy:
          steps:
          - checkout: self
          - task: KubernetesManifest@0
            displayName: Deploy canary
            inputs:
              action: $(strategy.action)
              namespace: smi
              strategy: $(strategy.name)
              trafficSplitMethod: smi
              percentage: $(strategy.increment)
              baselineAndCanaryReplicas: 1
              manifests: |
                manifests/deployment.yml
                manifests/service.yml
              imagePullSecrets: $(secretName)
              containers: '$(containerRegistry)/$(imageRepository):$(Build.BuildId)'
        postRouteTraffic:
          pool: server
          steps:
            - task: Delay@1
              inputs:
                delayForMinutes: '2'

环境中的 ReviewApp

ReviewApp 将 Git 存储库中的每个拉取请求部署到动态环境资源。 在将这些更改合并到主分支并部署到生产环境之前，审阅者可以查看这些更改的效果以及与其他依赖服务的协作情况。 这样可以轻松创建和管理 reviewApp 资源，并受益于环境功能的所有可跟踪性和诊断功能。 通过使用 reviewApp 关键字，可以创建资源的克隆（基于环境中的现有资源动态创建新资源），并将新资源添加到环境中。

下面是在环境下使用 reviewApp 的 YAML 片段示例。

jobs:
- deployment:
  environment: 
     name: smarthotel-dev      
     resourceName: $(System.PullRequest.PullRequestId) 
  pool:
    name: 'ubuntu-latest'
  strategy:                 
    runOnce:            
      pre-deploy: 
        steps:       
        - reviewApp: MainNamespace

后续步骤

注意

这些功能将在未来两到三周内推出。

前往 Azure DevOps 并了解一下。

转到 Azure DevOps

如何提供反馈

我们很想听听你对这些功能的看法。 使用帮助菜单报告问题或提供建议。

你还可以在 Stack Overflow 上获得社区的建议和问题的答案。

谢谢

杰夫·比勒