Azure Pipelines - スプリント160アップデート

機能

• 多段階パイプラインユーザーエクスペリエンス
• Kubernetes の環境に関するカナリア デプロイ戦略の調整
• YAML パイプラインの承認ポリシー
• 最上位クラスのパイプライン リソースとしての ACR
• 定義済み変数としてのパイプライン リソース メタデータ
• パイプラインと ACR リソースの追跡可能性
• YAML パイプラインでのリソース承認の簡素化
• アクセス トークンのスコープを制限することによるパイプラインのセキュリティの強化
• 成果物チェックの評価
• 自動テストのエラー メッセージでのマークダウンのサポート
• YAML での cron スケジュールの診断
• ARM テンプレートのデプロイ タスクの更新
• サービス接続のプロジェクト レベルのセキュリティ
• Ubuntu 18.04 プール
• KubernetesManifest タスクでの Service Mesh Interface ベースのカナリア デプロイ
• 環境内の ReviewApp

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

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

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

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

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

注

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

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'
      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 のカナリア戦略では、まず 10% のポッドで変更をデプロイし、次に 20% のポッドでデプロイしながら、postRouteTraffic の実行中に正常性を監視します。 すべてが問題なく進行した場合は、100% に昇格されます。

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

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

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

最上位クラスのパイプライン リソースとしての 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 にプッシュされたときに、パイプラインをトリガーできます。

  

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

  

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

• その実行で利用可能なアーティファクト。

  

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

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

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

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

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

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

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

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

  注

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

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

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

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

成果物チェックの評価

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

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

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

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

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

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

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

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

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

Ubuntu 18.04 プール

Azure Pipelines では、Ubuntu 18.04 でのジョブの実行がサポートされるようになりました。 Ubuntu-18.04 イメージを含むように、Microsoft がホストする Azure Pipelines プールを更新しました。 YAML パイプラインのubuntu-latestプールを参照する場合、ubuntu-18.04ではなくubuntu-16.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: MainNamespace

次のステップ

注

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

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

Azure DevOps に移動する

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

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

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

よろしくお願いします。

ジェフ・ビーラー