Azure Pipelines - Sprint 150 Update

  • [アーティクル]

機能

Kubernetes マニフェスト タスク

マニフェスト ファイルを使用して Kubernetes クラスターにデプロイするプロセスを簡略化するために、リリース パイプラインに新しいタスクを追加しました。 このタスクは、スクリプトでの kubectl バイナリの使用と比較して、次の利点を提供します。

  • 成果物の置換 - デプロイ アクションは、タグまたはダイジェストと共に指定できるコンテナー イメージの一覧を入力として受け取ります。 これは、クラスターに適用する前に、テンプレート以外のバージョンのマニフェスト ファイルに置き換えて、イメージの適切なバージョンがクラスターのノードによって確実にプルされるようにします。

  • マニフェストの安定性 - タスクの状態を成功または失敗として計算するときに安定性チェックを組み込むためにデプロイされた Kubernetes オブジェクトのロールアウト状態がチェックされます。

  • 追跡可能性の注釈 - 注釈がデプロイされた Kubernetes オブジェクトに追加され、元のorganization、プロジェクト、パイプライン、実行に関する追跡可能性情報が重ねられます。

  • マニフェストのベイク - タスクのベイク アクションを使用すると、Helm チャートを Kubernetes マニフェスト ファイルにベイクして、クラスターに適用できます。

  • デプロイ戦略 - デプロイ アクションを使用してカナリア戦略を選択すると、タスクの昇格/拒否アクションを使用して保持するバージョンを最終処理する前に、タスク中ManualInterventionに比較できるように、-baseline と -canary でサフィックスが付いたワークロードの望ましい割合が作成されます。

steps:
- task: KubernetesManifest@0
  name: bake
  displayName: Bake K8s manifests from Helm chart
  inputs:
    action: bake
    helmChart: charts/sample
    overrides: 'image.repository:nginx'

- task: KubernetesManifest@0
  displayName: Deploy K8s manifests
  inputs:
    kubernetesServiceConnection: k8sSC1
    manifests: $(bake.manifestsBundle)
    containers: |
      nginx: 1.7.9

Docker タスクへのアップグレード

パイプライン作成エクスペリエンスを簡略化するために Docker タスクをアップグレードしました。 buildAndPush コマンドを使用して、特定のコンテナー リポジトリの複数のタグをビルドし、1 つの手順で複数のコンテナー レジストリにプッシュできるようになりました。 タスクでは、コンテナー レジストリへのログインに Docker レジストリ サービス接続を使用できます。 ソース リポジトリ、コミット、ビルドの実績に関する追跡可能性メタデータは、このタスクを使用してビルドされたイメージにラベルとして追加されます。

steps:
- task: Docker@2
  displayName: Container registry login - ACR1 service connection
  inputs:
    command: login
    containerRegistry: acr1
- task: Docker@2
  displayName: Container registry login - ACR2 service connection
  inputs:
    command: login
    containerRegistry: acr2
- task: Docker@2
  displayName: Build and push images
  inputs:
    repository: test
    tags: |
      d1
      d2

Kubectl ツール インストーラー

エージェントに特定のバージョンの Kubectl バイナリをインストールできる新しいタスクが追加されました。 'v1.14.0' などの 最新 および semver バージョンの文字列は、Kubectl Version Spec 入力の有効な値として受け入れられます。

kubectl ツール インストーラー。

Docker レジストリ サービス接続での Azure コンテナー レジストリ

これで、プロジェクトの設定ページから Docker レジストリ サービス接続を作成できます。 接続を作成するには、Azure Active Directory (Azure AD) ID に関連付けられているサブスクリプションのいずれかで Azure コンテナー レジストリを選択します。 Docker@2やKubernetesManifest@0など、コンテナー レジストリへのサービス接続を必要とするすべてのタスクは、接続を指定する単一の方法をサポートします。

Docker サービス接続を追加します。

ホストされている Ubuntu プールでの cgroup のサポート

Linux では、メモリ使用量が多すぎると、カーネルは残りの部分を保護するために一部のプロセスを終了します。 終了のために Azure Pipelines エージェント プロセスが選択されている場合、パイプラインの実行は失敗し、エージェントとの通信が失われるというエラー メッセージが表示されます。 Microsoft がホストする Ubuntu プールでは、カスタム cgroup 内で手順を実行することで、エージェントが終了する可能性を減らしました。 使用可能なメモリを超えるとパイプラインが失敗する可能性はありますが、エージェント プロセスは存続し、エラーを正しく報告する可能性が高くなります。 プライベート Linux エージェントを実行する場合は、同様のセットアップを検討できるように、使用する設定が 公開 されています。

エージェントを 1 回実行する

Azure Container Instancesなどのインフラストラクチャを使用してエラスティック プライベート エージェントを実行する場合は、多くの場合、各エージェントが 1 つのジョブのみを受け入れてから退席する必要があります。 これまでは、エージェントを終了する (エラーが報告される可能性がある) か、シャットダウンする前にエージェントが別のジョブを受け取る可能性があるリスクを受け入れる必要があるため、これは簡単ではありませんでした。 この更新プログラムでは、エージェント構成に --once フラグを追加しました。 この方法でエージェントを構成すると、1 つのジョブのみが受け入れられ、シャットダウンされます。

Visual Studio テスト タスクでの Visual Studio 2019 (VS2019) のサポート

パイプラインの Visual Studio テスト タスクに VS2019 のサポートを追加しました。 VS2019 のテスト プラットフォームを使用してテストを実行するには、[テスト プラットフォームのバージョン] ドロップダウンから [ 最新 ] または [ Visual Studio 2019 ] オプションを選択します。

Visual Studio テスト タスクでの Visual Studio 2019 (VS2019) のサポート。

エージェント プールのユーザー インターフェイスの更新

プロジェクト設定のエージェント プール管理ページが、新しいユーザー インターフェイスで更新されました。 これで、プールで実行されているすべてのジョブを簡単に確認できます。 さらに、ジョブが実行されていない理由も学習できます。

エージェント プールのユーザー エクスペリエンス (UX) の更新。

YAML ファイルを編集するためのタスク アシスタント

パイプラインの YAML ファイルの編集を容易にするよう求める多くのフィードバックを引き続き受け取っています。 以前の更新プログラムでは、Intellisense のサポートが追加されました。 次に、タスク アシスタントを YAML エディターに追加します。 これにより、クラシック エディターと同じ使い慣れたエクスペリエンスで、YAML ファイルに新しいタスクを追加できます。 この新しいアシスタントでは、選択リストやサービス接続など、一般的なタスク入力の種類のほとんどがサポートされています。 新しいタスク アシスタントを使用するには、YAML ベースのパイプラインで [編集] を選択し、[タスク] アシスタントを選択します。

YAML ファイルを編集するためのタスク アシスタント。

ホストされているパイプライン イメージの更新

ホストされている macOS プール の OS X Mojave (10.4) への更新プログラムをお知らせします。これには Xcode 10.2 のサポートも含まれます。 デザイナー ベースのパイプラインで Hosted macOS プールを使用している場合、パイプラインは自動的に Mojave にアップグレードされます。 OS X High Sierra (10.3) を使用する場合は、ビルドを実行するプールを ホスト型 macOS High Sierra に変更します。

YAML を使用している場合、使用できる新しい vmImage ラベルは次のとおりです。

  • 常に最新バージョンの macOS (現在は 10.4) を指す画像ラベル
vmImage: 'macOS-latest'
  • パイプラインが Mojave に対して確実に実行されるようにする場合は、このイメージ ラベルは特に mac OS 10.4 を対象としています
vmImage: 'macOS-10.4'
  • パイプラインが High Sierra に対して確実に実行されるようにする場合は、mac OS 10.3 を具体的に対象とするイメージ ラベル
vmImage: 'macOS-10.3'

また、ホストされている Azure Pipelines の Windows Server 2019 イメージの更新も行いました。 最新のリリースについては、 こちらを参照してください。 この更新プログラムには、VS2019 プレビュー、Docker、PowerShell Core、Node.js、npm などの新しいバージョンが含まれています。

ホストされている macOS VM イメージに含まれている内容の詳細と、イメージで使用できるツールの詳細については、GitHub の Image Generation リポジトリ を参照してください。

ServiceNow 統合の機能強化

昨年 12 月、ServiceNow Change Management とリリース パイプラインの統合がリリースされました。 各チームが任意のサービスを使用し、効果的なエンドツーエンドの配信を可能にした、チーム間コラボレーションの重要な機能。 この更新プログラムでは、すべての種類の変更 (通常、標準、緊急) をサポートするように統合が強化されました。 さらに、organizationの ITSM プロセスに従って、既存のテンプレートを使用して新しい変更要求を作成するために使用するゲートを指定できるようになりました。 最後に、既存の変更要求に基づいてリリースをゲートすることもできます。 これにより、IT チームが推奨するプロセスを変更することなく、CD を採用できます。

ServiceNow の変更管理。

Azure PowerShell Az モジュールのサポート

Azure PowerShellには、コマンド ラインから Azure リソースを管理するために使用できる一連のコマンドレットが用意されています。 昨年 12 月、Azure PowerShell Az モジュールが利用可能になり、Azure リソースを管理するための目的のモジュールになりました。

以前は、ホストされているエージェントで Azure PowerShell Az モジュールのサポートを提供していませんでした。 ビルド パイプラインとリリース パイプラインの新しいAzure PowerShell タスク バージョン 4.* により、すべてのプラットフォームに対する新しい Az モジュールのサポートが追加されました。 タスク バージョン 3.* Azure PowerShell、引き続き AzureRM モジュールがサポートされます。 ただし、最新の Azure サービスと機能に対応するには、できるだけ早く Azure PowerShell タスク バージョン 4.* に切り替えてお勧めします。

Az モジュールには互換性モードがあり、既存のスクリプトを使用しながら新しい構文を使用するように更新できます。 Az モジュールの互換性を有効にするには、 コマンドを Enable-AzureRmAlias 使用します。 エイリアスを使用すると、Az モジュールで古いコマンドレット名を使用できます。 Azure RM モジュールから Azure PowerShell Az モジュールへの移行の詳細については、こちらを参照してください。

注意

プライベート エージェントを使用している場合は、エージェント コンピューターに Az モジュールをインストールする必要があります。

Azure PowerShell Az モジュールの詳細については、こちらのドキュメントを参照してください。

リソース承認の機能強化

YAML ファイルで参照されている場合は、保護されたリソース (サービス接続、変数グループ、エージェント プール、セキュリティで保護されたファイルなど) のセキュリティを提供する必要があります。 同時に、これらの種類のリソースを非運用シナリオに使用するパイプラインを簡単に設定して使用できるようにしたいと考えました。 以前は、リソースを "すべてのパイプラインでの使用が承認されました" としてマークする設定を追加しました。

この更新プログラムを使用すると、リソースをそのようにマークしていない場合でも、リソース承認の問題を簡単に修正できます。 新しいエクスペリエンスでは、リソース承認エラーが原因でビルドが失敗すると、パイプラインでこれらのリソースの使用を明示的に承認してから続行するオプションが表示されます。 リソースを承認するアクセス許可を持つチーム メンバーは、失敗したビルドから直接このアクションを完了できます。

承認エラーを含むパイプラインの概要。

ビルド パイプラインの簡略化された保持ポリシー

YAML ビルドを含むすべてのビルド パイプラインのリテンション期間モデルを簡略化しました。 プロジェクト レベルには、各パイプラインのビルドを保持する日数と、各ビルドの成果物を保持する日数を制御できる新しい設定があります。 クラシック エディターを使用してビルド パイプラインを作成した場合、古い保持設定は引き続き適用されますが、新しいパイプラインでは新しい設定が使用されます。 保持期間は、プロジェクト設定のパイプライン設定ページで管理できます。

リリースで自動的にフェッチされたパイプライン成果物

以前は、リリースにリンクされたビルド パイプラインで 、パイプライン成果物の発行タスクを使用して成果物が 発行 されていた場合、成果物はリリース時に自動的にフェッチされませんでした。 代わりに、成果物をダウンロードするために、リリース パイプラインにパイプライン成果物のダウンロード タスクを明示的に追加する必要がありました。

これで、ビルド パイプラインによって発行されたすべてのパイプライン成果物が自動的にダウンロードされ、リリースで使用できるようになります。 リリース パイプラインのフェーズ プロパティからパイプライン成果物のダウンロードをカスタマイズすることもできます。

Cobertura コード カバレッジ レポートの更新

以前は、パイプラインでテストを実行し、コード カバレッジの結果を Azure DevOps に発行した場合は、XML の概要と HTML レポート ファイルの両方を指定する必要があります。 さらに、HTML レポートのスタイルは、コード カバレッジ タブに表示される前に削除されました。このスタイル設定の削除は、任意の HTML ファイルをアップロードできるため、セキュリティの観点から必要でした。

この更新プログラムでは、Cobertura カバレッジ レポートに関するこれらの制限に対処しました。 コード カバレッジ レポートを発行するときに、HTML ファイルを指定する必要がなくなりました。 レポートは自動的に生成され、[コード カバレッジ] タブに適切なスタイル設定で表示されます。この機能では、オープンソース ツール ReportGenerator を使用します。

コード カバレッジ。

次の手順

Note

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

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

Azure DevOps に移動する

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

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

ご提案の送信

Stack Overflow のコミュニティが回答したアドバイスや質問を受けることもできます。

よろしくお願いします。

Jeremy Epling