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

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

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

Azure DevOps 中的新增功能

功能

Azure Repos：

• 跨存储库分支策略管理

Azure Pipelines：

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

Azure Artifacts：

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

报表：

• 包含你一直要求的所有内容的冲刺燃烧小组件

Wiki：

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

Azure Repos

跨存储库分支策略管理

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

Azure Pipelines

多阶段管道 UX

我们一直在致力于提供更新的用户体验来管理管道。 这些更新使管道体验现代且符合 Azure DevOps 的方向。 此外，这些更新将经典生成管道和多阶段 YAML 管道整合到一个体验中。 例如，以下功能包含在新体验中：查看和管理多个阶段、批准管道运行、在管道仍在进行时一直滚动回日志的功能，以及管道的每个分支运行状况。

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

多亏了你的反馈，我们在最近两次更新中解决了以下问题。

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

注意

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

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

持续交付应用程序更新的主要优点之一是能够快速将特定微服务的更新推送到生产环境。 这使你能够快速响应业务需求的变化。 环境 作为一流概念引入，可实现部署策略的业务流程，并实现零停机时间发布。 以前，我们支持 runOnce 策略，该策略按顺序执行一次步骤。 借助多阶段管道中对金丝雀策略的支持，现在可以通过缓慢地向小子集推出更改来降低风险。 随着你对新版本越来越有信心，你可以开始将其推广到基础结构中的更多服务器，并将更多用户路由到该版本。

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 的金丝雀策略将首先部署包含 10% Pod 后跟 20% 的更改，同时在 PostRouteTraffic 期间监视运行状况。 如果一切顺利，它将提升到100%。

我们正在寻找有关环境中 VM 资源支持以及跨多台计算机执行滚动部署策略的早期反馈。 联系我们 进行注册。

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 管道，你没有这种控制。 通过此更新，我们将引入一个组织设置，以强制每个作业获取项目范围的令牌，无论管道中配置了什么。 我们还在项目级别添加了 设置。 现在，你创建的每个新项目和组织都将自动启用此设置。

  注意

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

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

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

  默认情况下，我们将向访问令牌授予多个权限，其中一个权限是 队列生成。 在此更新中，我们删除了访问令牌的此权限。 如果管道需要此权限，可以将其显式授予 Project Build Service Account 或 Project Collection Build Service Account ，具体取决于所使用的令牌。

评估项目检查

现在可以定义一组策略，并将策略评估添加为容器映像项目的环境检查。 管道运行时，执行会在启动使用环境的阶段之前暂停。 根据所部署映像的可用元数据评估指定的策略。 当策略成功时，检查通过，并在检查失败时将阶段标记为失败。

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

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

在 YAML 中诊断 cron 计划

我们发现，在 YAML 管道中指定计划的 cron 语法的使用稳步增加。 当我们听取你的反馈时，我们听说你很难确定 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 任务中基于服务网格接口的金丝雀部署

以前，在 KubernetesManifest 任务中指定金丝雀策略时，该任务将创建基线和金丝雀工作负载，其副本等于用于稳定工作负载的副本的百分比。 这与在请求级别将流量拆分为所需百分比并不完全相同。 为了解决此问题，我们向 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 将 Git 存储库中的每个拉取请求部署到动态环境资源。 在将这些更改合并到 main 分支并部署到生产环境之前，审阅者可以查看这些更改的外观以及其他依赖服务。 这将使你能够轻松创建和管理 reviewApp 资源，并受益于环境功能的所有可跟踪性和诊断功能。 通过使用 reviewApp 关键字 (keyword) ，可以创建资源的克隆 (基于环境中的现有资源动态创建新资源) 并将新资源添加到环境中。

下面是在环境中使用 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 或创建公共源，然后将项目转换为私有来创建项目范围的源。 现在，如果具有所需的权限，可以直接在门户中从任何项目创建项目范围的源。 还可以在源选取器中查看哪些源是项目源，哪些源属于组织范围。

报表

包含你一直要求的所有内容的冲刺进度小组件

新的“冲刺进度”小组件支持按故事点数、任务计数或自定义字段求和进行刻录。 你甚至可以为功能或长篇故事创建冲刺进度。 小组件显示平均进度、完成百分比和范围增加。 可以配置团队，以便在同一仪表板上显示多个团队的冲刺进度。 通过显示所有这些出色的信息，我们允许你在仪表板上将其大小调整为 10x10。

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

注意

新小组件使用 Analytics。 我们保留了旧版 Sprint Burndown，以防你无权访问 Analytics。

Wiki

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

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

注意

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

Wiki 页面的页面访问数

现在可以深入了解 Wiki 页面的页面访问量。 REST API 允许访问过去 30 天内访问的页面信息。 可以使用此数据为 Wiki 页面创建报表。 此外，还可以将此数据存储在数据源中，并创建仪表板以获取特定见解，例如 排名靠前的 N 个页面。

你还将在每个页面中看到过去 30 天的总页面访问计数。

注意

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

后续步骤

注意

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

前往 Azure DevOps 并了解一下。

转到 Azure DevOps

如何提供反馈

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

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

此致

Jeff Beehler