新的冲刺进度小组件和改进的管道安全性 - Sprint 160 更新

在 Azure DevOps 的 Sprint 160 更新中，我们添加了一个新的冲刺进度小组件，该小组件支持按故事点、任务计数和对自定义字段求和来向下燃烧。 此外，我们通过限制访问令牌的范围来改进管道安全性。

有关详细信息， 请查看下面的功能 列表。

Azure DevOps 中的新增功能

功能

Azure Repos：

• 跨 repo 分支策略管理

Azure Pipelines：

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

Azure Artifacts：

• 更新了连接到源体验
• 公共源现提供正式发布版，并且支持上游
• 从门户创建项目范围的源

报表：

• 包含已请求的所有内容的冲刺 (sprint) 燃尽小组件

Wiki：

• 用于编辑 Wiki 页面的同步滚动
• Wiki 页面的页面访问

Azure Repos

跨存储库分支策略管理

分支策略是 Azure Repos 的一项强大功能，可帮助你保护重要的分支。 尽管 REST API 中存在在项目级别设置策略的功能，但没有相应的用户界面。 现在，管理员可以在其项目中所有存储库的特定分支或默认分支上设置策略。 例如，管理员可能需要对项目中每个存储库中每个主分支进行的所有拉取请求的两个最低审阅者。 可以在 Repos 项目设置中找到“添加分支保护 ”功能。

Azure Pipelines

多阶段管道用户体验

我们一直在努力更新和优化管道管理方面的用户体验。 这些更新可实现管道体验的现代化，并与 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'
      postRouteTaffic:
        pool: server
        steps:          
        - script: echo monitor application health...  
      on:
        failure:
          steps:
	  - script: echo clean-up, rollback...  
        success:
          steps:
          - script: echo checks passed, notify...

Kuberenetes 的 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 容器资源时，我们确保提供完整的 E2E 可追溯性。 对于 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 策略时，该任务将创建基线和 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: MasterNamespace

Azure Artifacts

更新了连接到源体验

“连接到源”对话框是使用 Azure Artifacts 的入口；它包含有关如何配置客户端和存储库以从 Azure DevOps 中的源中推送和拉取包的信息。 我们更新了该对话框以添加详细的设置信息，并扩展了我们为其提供说明的工具。

公共源现提供正式发布版，并且支持上游

公共源的公共预览版已获得广泛采用并收到了大量反馈。 在此更新中，我们扩展了其他功能，正式发布。 现在，你可以将公共源设置为专用源的上游源。 通过在专用和项目范围内的源之间进行上游操作，可以使配置文件保持简单。

从门户创建项目范围的源

发布公共源时，我们还发布了项目范围的源。 到目前为止，可以通过 REST API 创建项目范围内的源，也可以通过创建公共源，然后将项目变成专有项目，从而创建项目范围内的源。 现在，如果拥有所需的权限，可以直接在门户中从任何项目创建项目范围的源。 还可以查看哪些源是项目，哪些源在源选取器中具有组织范围。

正在报告

包含已请求的所有内容的冲刺 (sprint) 燃尽小组件

新的冲刺 (Sprint) 燃尽小组件支持按故事点、任务计数或汇总自定义字段燃尽。 你甚至可为功能或长篇故事创建冲刺 (sprint) 燃尽。 此小组件显示平均燃尽量、完成百分比和范围增加。 你可以配置团队，以便在同一仪表板上显示多个团队的冲刺 (sprint) 燃尽。 若要显示所有这些有用信息，你可在仪表板上将其大小调整为 10x10。

若要试用，可以从小组件目录添加它，也可以编辑现有 Sprint Burndown 小组件的配置并选中“ 立即 试用新版本”框。

注意

新小组件使用 Analytics。 我们保留了旧版冲刺 (sprint) 燃尽，以防你无权访问 Analytics。

Wiki

用于编辑 Wiki 页面的同步滚动

现在，通过在编辑和预览窗格之间进行同步滚动，可以更轻松地编辑 Wiki 页面。 在一侧滚动将自动在另一侧滚动，以映射相应的部分。 你可以使用切换按钮禁用同步滚动。

注意

同步滚动切换的状态是按用户和组织保存的。

Wiki 页面的页面访问数

你现在可以深入了解 Wiki 页面的页面访问。 通过 REST API，你可以访问最近 30 天内的页面访问信息。 你可以使用此数据为 Wiki 页面创建报告。 此外，还可以将此数据存储在数据源中，并创建仪表板以获取特定的见解，例如浏览量排名第 N 位的页面。

你还将在每个页面中看到最近 30 天的页面访问量汇总。

注意

页面访问定义为给定用户在 15 分钟的间隔内的页面视图。

后续步骤

注意

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

前往 Azure DevOps 并了解一下。

转到 Azure DevOps

如何提供反馈

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

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

此致

Jeff Beehler