クラシックパイプライン非推奨後のAzure Pipelinesの変更点とAZ-400のラーニングパスの変更箇所について調べる
クラシックパイプラインからYAMLベースでのパイプラインへ
Azure DevOpsでクラシックパイプラインの作成が2023年6月以降新規のOragnizationでは既定ではOFFになりました。
これにより、Azure Pipelinesでのパイプラン作成はYAMLファイルでの作成がスタンダードとなります。
クラシックパイプライン以前と以降での変更点
以前こちらのスレッドでクラシックパイプラインで提供されていた機能と、YAMLベースでのパイプラインのマッピングを整理したので、備忘がてらこちらに記載しておきます。
-
承認ゲート(デプロイ前に手動で承認させたりクエリ結果引っ張ってきて特定の作業項目の数が何件以上だったらとかの条件つけるやつ)→EnvironmentのApprovals & Checks
https://learn.microsoft.com/ja-jp/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass -
配置グループジョブ(デプロイターゲット環境をdevとかstgとか論理的にグルーピングするやつ)→Environmentで環境定義して、YAMLのデプロイジョブのEnvironment:のとこで定義した環境の名前を指定
https://learn.microsoft.com/ja-jp/azure/devops/pipelines/process/environments?view=azure-devops -
タスクグループ→YAMLでテンプレートファイル用意してそこに再利用したいタスク群を定義
AZ-400のラーニングパスの変更点
Azure DevOpsでクラシックパイプラインの作成が2023年6月以降新規のOragnizationでは既定ではOFFになりました。
これにより、Azure Pipelinesでのパイプラン作成はYAMLファイルでの作成がスタンダードとなります。
クラシックパイプライン以前と以降での変更点
以前こちらのスレッドでクラシックパイプラインで提供されていた機能と、YAMLベースでのパイプラインのマッピングを整理したので、備忘がてらこちらに記載しておきます。
-
承認ゲート(デプロイ前に手動で承認させたりクエリ結果引っ張ってきて特定の作業項目の数が何件以上だったらとかの条件つけるやつ)→EnvironmentのApprovals & Checks
https://learn.microsoft.com/ja-jp/azure/devops/pipelines/process/approvals?view=azure-devops&tabs=check-pass -
配置グループジョブ(デプロイターゲット環境をdevとかstgとか論理的にグルーピングするやつ)→Environmentで環境定義して、YAMLのデプロイジョブのEnvironment:のとこで定義した環境の名前を指定
https://learn.microsoft.com/ja-jp/azure/devops/pipelines/process/environments?view=azure-devops -
タスクグループ→YAMLでテンプレートファイル用意してそこに再利用したいタスク群を定義
https://learn.microsoft.com/ja-jp/azure/devops/pipelines/yaml-schema/?view=azure-pipelines
AZ-400のラーニングパスの変更点
上記の変更に伴い、以下のラーニングパスのモジュールが影響を受ける想定です。
代わりに参照するべきドキュメントを表に記載しています。# | モジュール第1階層 | モジュール第2階層 | 理由 | アップデートに合わせて参照すべきdocs |
---|---|---|---|---|
1 | リリースパイプラインを作成する | リリースパイプラインを確認する | GUIによるリリースパイプラインの構成はクラシックパイプラインの機能である。YAMLベースでのパイプラインによるリリースは、YAMLファイルでマルチステージパイプラインを構成してその中に定義する。 | チュートリアル: Azure DevOps を使用してマルチステージ パイプラインを作成する |
2 | - | 成果物ソースを確認する | クラシックリリースパイプラインの場合、成果物のソースをGUIで選択するが、YAMLの場合はdropという名前の成果物が暗黙的に発行され、それを使用する。 | パイプライン成果物を発行してダウンロードする |
3 | - | ステージを設定する | GUIでのリリースパイプラインでの各環境へのデプロイについて記載されている。最新版に従うなら、YAMLファイルでのマルチステージパイプラインを作成する。 | #1と同様 |
4 | - | ビルドおよびリリースタスクを確認する | GUIでのタスク構成について記載されている。YAMLでは'-task'プロパティで指定する。 | タスクの種類と応用 |
5 | リリースの推奨事項を調べる | 配布周期と3種類のトリガーについて理解する | クラシックパイプラインでのトリガーの設定について記載されている。YAMLベースでのパイプラインでは-trigerプロパティでトリガーを指定する。 |
スケジュールされたトリガー パイプライン完了トリガー |
6 | - | リリース承認を利用する | リリースに対して承認を挟むことは変わらず推奨されているものの、このdocsで参考として載せられている「リリース承認とゲートの概要」は最新アップデートではクラシックリリースパイプラインが廃止されたことにより、非推奨となる。代わりにEnvironmentのApproval & checkesを使用。 |
ターゲット環境を作成する 承認とチェックを定義する |
7 | - | 手動承認を設定する | 7の演習内容 | #6と同様 |
8 | - | リリースゲートを確認する | リリースゲートはクラシックリリースパイプラインでのみサポートされるため、最新のアップデートには合わない。従来のリリースパイプラインでの「ゲート」のユースケースとしては、Bugとかのwork itemの件数をクエリで引っ張ってきて、何件以上だったらリリースさせない、みたいな感じで使ってたっぽい。同じことがEnvironmentのApprovals and Checksでもできるみたい。 | #6の「承認とチェック」と同様 |
9 | - | リリースゲートを使用して品質を保護する | リリースゲートの話なので同上 | #6の「承認とチェック」と同様 |
10 | - | リリースゲートを使用したデプロイの制御 | ↑の演習 | #6の「承認とチェック」と同様 |
11 | タスクとテンプレートを管理してモジュール化する | タスクグループを調べる | タスクグループはクラシックパイプラインのみでYAMLではサポートされていない。YAMLでタスクグループに相当するものを定義するためには、テンプレートがいるを作成し、その中に再利用したいタスク群を定義する。 | Azure PipelinesのYAMLスキーマリファレンス |
Discussion