新しいスプリント バーンダウン ウィジェットと強化されたパイプラインのセキュリティ - Sprint 160 Update

  • [アーティクル]

Azure DevOps の Sprint 160 Update では、ストーリー ポイント、タスクの数、およびカスタム フィールドの合計による書き込みをサポートする新しいスプリント バーンダウン ウィジェットが追加されました。 さらに、アクセス トークンのスコープを制限することで、パイプラインのセキュリティが強化されました。

詳細については、以下の Features 一覧を参照してください。

Azure DevOps の新機能

機能

Azure Repos:

Azure Pipelines:

Azure Artifacts:

レポート:

Wiki

Azure Repos

リポジトリ間でのブランチ ポリシーの管理

ブランチ ポリシーは、重要なブランチを保護するのに役立つ Azure Repos の強力な機能の 1 つです。 プロジェクト レベルでポリシーを設定する機能は REST API に存在しますが、ユーザー インターフェイスはありませんでした。 管理者は、プロジェクト内のすべてのリポジトリで特定のブランチまたは既定のブランチにポリシーを設定できるようになりました。 たとえば、管理者は、プロジェクト内のすべてのリポジトリのすべてのメイン ブランチに対して行われたすべてのプル要求に対して、2 つの最小レビュー担当者を要求できます。 ブランチ保護の追加機能は、[Repos Project Settings]\(リポジトリ プロジェクトの設定\) で確認できます。

リポジトリ間ブランチ ポリシーの管理。

Azure Pipelines

複数ステージ パイプライン UX

パイプラインを管理するために、更新されたユーザー エクスペリエンスに取り組んできました。 これらの更新により、パイプラインのエクスペリエンスが最新になり、Azure DevOps の方向性と一貫性が保たれます。 さらに、これらの更新により、クラシック ビルド パイプラインとマルチステージ YAML パイプラインが 1 つのエクスペリエンスにまとめられます。 たとえば、新しいエクスペリエンスには次の機能が含まれています。複数のステージの表示と管理、パイプラインの実行の承認、パイプラインの進行中にログに戻るスクロール機能、およびパイプラインのブランチごとの正常性。

新しい経験を試したすべての人に感謝します。 試していない場合は、プレビュー機能で マルチステージ パイプライン を有効にします。 マルチステージ パイプラインの詳細については、 こちら のドキュメントを参照してください。

マルチステージ パイプライン UX。

ご意見をお寄せいただき、最後の 2 つの更新プログラムで次の点に対処しました。

  1. フォルダー ビューの検出可能性。
  2. ログ ビューの Jumpiness。
  3. 実行が進行中であっても、以前のタスクと現在のタスクのログを簡単に表示できます。
  4. ログを確認するときにタスク間を簡単に移動できるようにします。

新しいエクスペリエンスに含まれる機能。

Note

次の更新では、すべてのユーザーに対してこの機能を既定で有効にする予定です。 プレビューをオプトアウトすることもできます。 その数週間後に、この機能が一般公開されます。

Kubernetes の環境に関するカナリア デプロイ戦略の調整

アプリケーション更新プログラムの継続的デリバリーの主な利点の 1 つは、特定のマイクロサービスの運用環境に更新プログラムをすばやくプッシュできることです。 これにより、ビジネス要件の変化に迅速に対応できます。 環境 は、デプロイ戦略のオーケストレーションを可能にし、ダウンタイムゼロのリリースを容易にする第一級の概念として導入されました。 以前は、 runOnce の戦略をサポートしました。この戦略では、手順を順番に 1 回実行しました。 マルチステージ パイプラインでのカナリア戦略のサポートにより、変更を小さなサブセットに徐々にロールアウトすることで、リスクを軽減できるようになりました。 新しいバージョンに対する信頼度が高まるにつれて、インフラストラクチャ内のより多くのサーバーへのロールアウトを開始し、より多くのユーザーをそれにルーティングできます。

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% のポッドで変更をデプロイし、その後に 20% をデプロイし、 postRouteTraffic の間に正常性を監視します。 すべてがうまくいけば、100%に昇格します。

YAML パイプラインの承認ポリシー

YAML パイプラインでは、リソース所有者が制御する承認構成に従います。 リソース所有者は、リソースに対する承認を構成し、リソースを使用するすべてのパイプラインは、リソースを使用するステージの開始前に承認のために一時停止します。 SOX ベースのアプリケーション所有者は、展開の要求者が独自のデプロイを承認できないように制限するのが一般的です。

追加の承認オプションを使用して要求者が承認しない、ユーザーのサブセットからの承認を要求する、承認タイムアウトなどの承認ポリシーを構成できるようになりました。

YAML パイプラインの承認ポリシー。

最上位クラスのパイプライン リソースとしての ACR

パイプラインの一部として ACR (Azure Container Registry) に発行されたコンテナー イメージを使用し、新しいイメージが発行されるたびにパイプラインをトリガーする必要がある場合は、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 にプッシュされたときに、パイプラインをトリガーできます。

    実行をトリガーしたリソースのバージョン。

  • パイプラインによって使用される commits 。 また、パイプラインによって使用される各リソースによるコミットの内訳を確認することもできます。

    パイプラインによって使用されるコミット。

  • パイプラインによって使用される各リソースに関連付けられている 作業項目 。

  • 実行で使用できる artifacts 。

    実行で使用できる成果物。

環境のデプロイ ビューでは、環境にデプロイされた各リソースのコミットと作業項目を確認できます。

環境にデプロイされた各リソースのコミットと作業項目。

YAML パイプラインでのリソース承認の簡素化

リソースは、パイプラインの外部にあるパイプラインによって使用されるあらゆるものです。 リソースを使用できるようにするには、その前にそれを承認する必要があります。 以前は、YAML パイプラインで未承認のリソースを使用すると、リソース承認エラーで失敗しました。 失敗した実行の概要ページからリソースを承認する必要がありました。 さらに、承認されていないリソースを参照する変数を使用していた場合、パイプラインは失敗しました。

リソース承認の管理が容易になりました。 実行は、実行に失敗するのではなく、リソースを使用するステージの開始時にリソースに対するアクセス許可を待機します。 リソース所有者は、パイプラインを表示し、[セキュリティ] ページからリソースを承認できます。

YAML パイプラインでのリソース承認の簡素化。

アクセス トークンのスコープを制限することによるパイプラインのセキュリティの強化

Azure Pipelines で実行されるすべてのジョブは、アクセス トークンを取得します。 アクセス トークンは、タスクとスクリプトによって使用され、Azure DevOps にコールバックされます。 たとえば、アクセス トークンを使用して、ソース コードの取得、ログのアップロード、テスト結果、成果物、または Azure DevOps への REST 呼び出しを行います。 ジョブごとに新しいアクセス トークンが生成され、ジョブが完了すると有効期限が切れます。 この更新プログラムでは、次の機能強化が追加されました。

  • トークンがチーム プロジェクト外のリソースにアクセスできないようにする

    これまで、すべてのパイプラインの既定のスコープはチーム プロジェクト コレクションでした。 スコープは、クラシック ビルド パイプラインのチーム プロジェクトに変更できます。 ただし、クラシック リリースまたは YAML パイプラインに対しては、そのコントロールがありませんでした。 この更新プログラムでは、パイプラインで構成されている内容に関係なく、すべてのジョブでプロジェクト スコープのトークンを取得するように強制する組織設定を導入します。 また、プロジェクト レベルで設定を追加しました。 これで、作成するすべての新しいプロジェクトと組織で、この設定が自動的に有効になります。

    Note

    組織の設定は、プロジェクト設定をオーバーライドします。

    既存のプロジェクトや組織でこの設定をオンにすると、パイプラインがアクセス トークンを使用してチーム プロジェクトの外部にあるリソースにアクセスすると、特定のパイプラインが失敗する可能性があります。 パイプラインの障害を軽減するために、 Project Build Service Account 目的のリソースへのアクセス権を明示的に付与できます。 これらのセキュリティ設定を有効にすることを強くお勧めします。

  • アクセス トークンの特定のアクセス許可を削除する

    既定では、アクセス トークンに対して多数のアクセス許可が付与されます。このアクセス許可の 1 つは Queue ビルドです。 この更新プログラムでは、アクセス トークンに対するこのアクセス許可を削除しました。 パイプラインにこのアクセス許可が必要な場合は、使用するトークンに応じて、 Project Build Service Account または Project Collection Build Service Account に明示的に付与できます。

成果物チェックの評価

一連のポリシーを定義し、コンテナー イメージ成果物の環境のチェックとしてポリシー評価を追加できるようになりました。 パイプラインを実行すると、環境を使用するステージを開始する前に実行が一時停止します。 指定されたポリシーは、デプロイされるイメージの使用可能なメタデータに対して評価されます。 このチェックは、ポリシーが成功したときに成功し、チェックが失敗した場合にステージを失敗としてマークします。

成果物チェックを評価します。

自動テストのエラー メッセージでのマークダウンのサポート

自動テストのエラー メッセージで Markdown がサポートされるようになりました。 テストの実行とテストの両方の結果のエラー メッセージを簡単に書式設定して、読みやすさを向上させ、Azure Pipelines でのエラーのトラブルシューティングを容易にすることができます。 サポートされている Markdown 構文は、 こちらにあります。

自動テスト エラー メッセージでの Markdown のサポート。

YAML での cron スケジュールの診断

YAML パイプラインでスケジュールを指定するための cron 構文の使用が着実に増加しています。 お客様のフィードバックに耳を傾ける中で、Azure Pipelines が構文を正しく処理したかどうかを判断するのは難しいと聞きました。 以前は、スケジュールされた実行の実際の時刻を待ってスケジュールの問題をデバッグする必要があります。 分岐/構文エラーの診断に役立つ、パイプラインの新しいアクション メニューが追加されました。 [実行パイプライン] メニューの Scheduled 実行 は、cron スケジュールでエラーを診断するのに役立つ、パイプラインに対して予定されているいくつかの実行のプレビューを提供します。

YAML での cron スケジュールの診断。

ARM テンプレートのデプロイ タスクの更新

以前は、ARM テンプレートのデプロイ タスクでサービス接続をフィルター処理しませんでした。 より低いスコープのサービス接続を選択して、より広範なスコープへの ARM テンプレートのデプロイを実行すると、デプロイが失敗する可能性があります。 次に、選択したデプロイ スコープに基づいて、下位スコープのサービス接続を除外するサービス接続のフィルター処理を追加しました。

サービス接続のプロジェクト レベルのセキュリティ

この更新プログラムにより、サービス接続のハブ レベルのセキュリティが追加されました。 これで、すべてのサービス接続の一元的な場所で、ユーザーの追加/削除、ロールの割り当て、アクセスの管理を行うことができます。

サービス接続のプロジェクト レベルのセキュリティ。

Ubuntu 18.04 プール

Azure Pipelines では、Ubuntu 18.04 でのジョブの実行がサポートされるようになりました。 Ubuntu-18.04 イメージを含むように、Microsoft がホストする Azure Pipelines プールを更新しました。 ここで、YAML パイプラインubuntu-latestプールを参照する場合、ubuntu-16.04ではなく、ubuntu-18.04を意味します。 ubuntu-16.04を明示的に使用して、ジョブで 16.04 個のイメージをターゲットにすることができます。

KubernetesManifest タスクでの Service Mesh Interface ベースのカナリア デプロイ

以前は、KubernetesManifest タスクでカナリア戦略が指定されていた場合、タスクは、安定したワークロードに使用されるレプリカの割合に等しいレプリカを持つベースラインワークロードとカナリア ワークロードを作成していました。 これは、要求レベルでトラフィックを目的の割合に分割するのとまったく同じではありません。 これに取り組むために、KubernetesManifest タスクに Service Mesh Interface ベースのカナリア デプロイのサポートを追加しました。

サービス メッシュ インターフェイスの抽象化により、Linkerd や Istio などのサービス メッシュ プロバイダーとのプラグ アンド プレイ構成が可能になります。 これで、KubernetesManifest タスクは、デプロイ戦略のライフサイクル中に、SMI の TrafficSplit オブジェクトを安定したベースラインおよびカナリア サービスにマッピングする作業を取り除きます。 サービス メッシュ プレーンの要求でトラフィック分割の割合が制御されるため、安定したベースラインとカナリアの間のトラフィックの必要な割合の分割がより正確になります。

SMI ベースのカナリアデプロイをローリング方式で実行するサンプルを次に示します。

- 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 を使用するか、パブリック フィードを作成してからプロジェクトをプライベートにすることで、プロジェクト スコープのフィードを作成できました。 これで、必要なアクセス許可がある場合は、任意のプロジェクトから直接、ポータルでプロジェクト スコープのフィードを作成できます。 また、どのフィードがプロジェクトで、どのフィードが組織スコープであるかをフィード ピッカーで確認することもできます。

レポート

あなたが求めているすべてのものを含むスプリントバーンダウンウィジェット

新しいスプリント バーンダウン ウィジェットでは、ストーリー ポイント、タスクの数、またはユーザー設定フィールドの合計による書き込みをサポートしています。 フィーチャーやエピックのスプリントバーンダウンを作成することもできます。 ウィジェットには、平均バーンダウン、達成率、スコープの増加が表示されます。 チームを構成して、同じダッシュボードに複数のチームのスプリント バーンダウンを表示できます。 この優れた情報をすべて表示して、ダッシュボードで最大 10 x 10 のサイズを変更できます。

スプリント バーンダウン ウィジェット。

これを試すには、ウィジェット カタログから追加するか、既存のスプリント バーンダウン ウィジェットの構成を編集し、 新しいバージョンを確認します ボックスをオンにします。

Note

新しいウィジェットでは Analytics が使用されます。 Analytics にアクセスできない場合に備えて、従来のスプリント バーンダウンを保持しました。

Wiki

Wiki ページを編集する際の同期スクロール

編集ウィンドウとプレビュー ウィンドウの間を同期スクロールすることで、Wiki ページの編集が簡単になりました。 一方の側をスクロールすると、対応するセクションをマップするために、もう一方の側が自動的にスクロールされます。 トグル ボタンを使用して同期スクロールを無効にすることができます。

Wiki ページを編集するための同期スクロール。

Note

同期スクロール トグルの状態は、ユーザーと組織ごとに保存されます。

Wiki ページのページ アクセス数

Wiki ページのページ アクセスに関する分析情報を取得できるようになりました。 REST API を使用すると、過去 30 日間のページ アクセス情報にアクセスできます。 このデータを使用して、Wiki ページのレポートを作成できます。 さらに、このデータをデータ ソースに格納し、ダッシュボードを作成して、 トップ n の最も閲覧数の多いページなど、特定の分析情報を取得。

また、すべてのページで過去 30 日間の合計ページ アクセス数も表示されます。

Wiki ページのページ アクセス。

Note

ページ 訪問は、15 分間隔で特定のユーザーによってページ ビューとして定義されます。

次のステップ

Note

これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。

Azure DevOps に向かい、見てみましょう。

Azure DevOps に移動する

フィードバックの提供方法

これらの機能に関するご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。

ご提案の送信

Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。

よろしくお願いします。

Jeff Beehler