リリースゲートを使用したデプロイの制御

ラボの要件

このラボには、Microsoft Edge または Azure DevOps 対応ブラウザーが必要です。
Azure DevOps 組織を設定する: このラボで使用できる Azure DevOps 組織がまだない場合は、組織またはプロジェクトコレクションの作成に関するページの手順に従って作成してください。
既存の Azure サブスクリプションを識別するか、新しいものを作成します。
Azure サブスクリプションの所有者ロールと、Azure サブスクリプションに関連付けられた Microsoft Entra テナントの全体管理者ロールを持つ Microsoft アカウントまたは Microsoft Entra アカウントがあることを確認します。詳細については、「Azure portal を使用して Azure ロールの割り当てを一覧表示する」および「Azure Active Directory で管理者ロールを表示して割当てる」を参照してください。

ラボの概要

このラボでは、デプロイゲートの構成と、それらを使用して Azure Pipelines の実行を制御する詳細な方法について説明します。それらの実装を説明するために、Azure Web アプリの 2 つの環境でリリース定義を構成します。アプリのブロッキングバグがない場合にのみ DevTest 環境にデプロイし、Azure Monitor の Application Insights にアクティブなアラートがない場合にのみ DevTest 環境を完了としてマークします。

リリースパイプラインは、さまざまな環境にデプロイされるアプリケーションのエンドツーエンドのリリースプロセスを指定します。各環境へのデプロイは、ジョブとタスクを使用して完全に自動化されます。アプリケーションに対する新しい更新プログラムは、すべてのユーザーに同時に公開しないことが理想です。ベストプラクティスは、更新プログラムを段階的に公開することです。つまり、ユーザーの 1 つのサブセットに公開し、使用状況を監視してから、その初期のユーザーセットの経験に基づいて他のユーザーにも公開することです。

承認とゲートにより、リリースのデプロイの開始と完了を制御できます。手動の承認を使用すると、ユーザーがデプロイを承認または拒否するのを待つことができます。リリースゲートを使用すると、リリースを次の環境にレベル上げする前に満たす必要のあるアプリケーション正常性基準を指定できます。環境デプロイの前または後に、指定されたすべてのゲートは、合格するか、定義されたタイムアウト期間に達して失敗するまで、自動的に評価されます。

ゲートは、デプロイ前の条件またはデプロイ後の条件パネルから、リリース定義の環境に追加できます。環境条件に複数のゲートを追加して、リリースに対するすべての入力が正常に行われるようにすることができます。

例

デプロイ前のゲートは、ビルドを環境にデプロイする前に、作業項目または問題管理システムにアクティブな問題がないことを確認します。
デプロイ後のゲートは、デプロイ後、次の環境にリリースをレベル上げする前に、アプリの監視またはインシデント管理システムからのインシデントがないことを確認します。

すべてのアカウントには、既定で 4 種類のゲートが含まれています。

Azure Function の呼び出し:Azure Function の実行をトリガーし、正常に完了するようにします。
Azure Monitor アラートのクエリ:アクティブなアラートの構成済みの Azure Monitor 警告ルールを確認します。
REST API の呼び出し:REST API を呼び出して、成功した応答が返されたら続行します。
作業項目のクエリ:クエリから返された一致する作業項目の数がしきい値内であることを確認してください。

目標

このラボを完了すると、次のことができるようになります。

リリースパイプラインを構成する。
リリースゲートを構成します。
リリースゲートをテストする。

推定時間:75 分

Instructions

演習 0:ラボの前提条件の構成

この演習では、ラボの前提条件を設定します。

タスク 1: (完了している場合はスキップしてください) チームプロジェクトを作成して構成する

このタスクでは、複数のラボで使用される eShopOnWeb Azure DevOps プロジェクトを作成します。

ラボコンピューターのブラウザーウィンドウで、Azure DevOps 組織を開きます。 [新しいプロジェクト] をクリックします。プロジェクトに「eShopOnWeb」という名前を付け、他のフィールドは既定値のままにします。 [作成] をクリックします。

タスク 2: (完了している場合はスキップしてください) eShopOnWeb Git リポジトリをインポートする

このタスクでは、複数のラボで使用される eShopOnWeb Git リポジトリをインポートします。

ラボコンピューターのブラウザーウィンドウで、Azure DevOps 組織と、前に作成した eShopOnWeb プロジェクトを開きます。 [リポジトリ]、[ファイル]、[リポジトリをインポートする] の順にクリックします。 インポート を選択します。 [Git リポジトリをインポートする] ウィンドウで、URL https://github.com/MicrosoftLearning/eShopOnWeb.git を貼り付けて、 [インポート] をクリックします。
リポジトリは次のように編成されています。
- .ado フォルダーには、Azure DevOps の YAML パイプラインが含まれています。
- .devcontainer フォルダーには、コンテナーを使って開発するためのセットアップが含まれています (VS Code でローカルに、または GitHub Codespaces で)。
- infra フォルダーには、一部のラボシナリオで使用される Bicep および ARM のコードとしてのインフラストラクチャテンプレートが含まれています。
- .github フォルダーには、YAML GitHub ワークフローの定義が含まれています。
- src フォルダーには、ラボシナリオで使用される .NET 8 Web サイトが含まれています。
[リポジトリ]、ブランチ の順に移動します。
main ブランチをポイントし、列の右側に表示される省略記号をクリックします。
[既定のブランチとして設定] をクリックします。

タスク 3: Azure DevOps で YAML を使用して CI パイプラインをコードとして構成する

このタスクでは、既存のプロジェクトに YAML ビルドの定義を追加します。

[パイプライン] ハブで [パイプライン] に戻ります。
[最初のパイプラインを作成] ウィンドウで、[パイプラインの作成] をクリックします。

注: ウィザードを使い、プロジェクトに基づいて新しい YAML パイプラインの定義を作成します。
[コードはどこにありますか?] ペインで [Azure Repos Git (YAML)] オプションをクリックします。
[リポジトリの選択] ペインで eShopOnWeb をクリックします。
[パイプラインを構成する] ペインで、 [既存の Azure Pipelines YAML ファイル] を選びます。
[既存の YAML ファイルを選択する] ペインで、次のパラメーターを指定します。
- パス: .ado/eshoponweb-ci.yml
[続行] をクリックして、これらの設定を保存します。
[パイプライン YAML をレビューする] 画面で [実行] をクリックして、ビルドパイプラインプロセスを開始します。
ビルドパイプラインが正常に完了するまで待ちます。ソースコード自体に関する警告は無視します。これらは、このラボ演習には関係ありません。

注:警告やエラーなど、YAML ファイルの各タスクをレビューできます。
パイプラインには、プロジェクト名に基づく名前が付けられます。パイプラインを識別しやすくするために、名前を変更しましょう。 [パイプライン] - [パイプライン] に移動し、先ほど作成したパイプラインをクリックします。省略記号と [名前の変更または移動] オプションをクリックします。 eshoponweb-ci という名前を付けて [保存] をクリックします。

演習 1: リリースパイプラインに必要な Azure リソースを作成する

タスク 1: 2 つの Azure Web アプリを作成する

このタスクでは、DevTest と運用環境を表す 2 つの Azure Web アプリを作成し、Azure Pipelines を介してアプリケーションをデプロイします。

ラボのコンピューターで Web ブラウザーを起動し、Azure portal に移動します。このラボで使用する Azure サブスクリプションで所有者のロールがあり、このサブスクリプションに関連付けられている Microsoft Entra テナントでグローバル管理者のロールがあるユーザーアカウントを使ってサインインします。
Azure portal で、ページ上部の検索テキストボックスのすぐ右側にある Cloud Shell アイコンをクリックします。
Bash または PowerShell の選択を求めるメッセージが表示されたら、[Bash] を選択します。

注: Cloud Shell を初めて起動し、[ストレージがマウントされていません] というメッセージが表示された場合は、このラボで使用しているサブスクリプションを選択し、[ストレージの作成] を選択します。
Bash プロンプトの [Cloud Shell] ペインで、次のコマンドを実行してリソースグループを作成します (<region> 変数プレースホルダーを 2 つの Azure Web アプリをホストする Azure リージョンの名前に置き換えます (たとえば、’westeurope’、’centralus’、またはその他の使用できる任意のリージョン))。

注: 使用できる場所を確認するには、次のコマンドを実行します。<region> の [名前] を使います: az account list-locations -o table
```
REGION='<region>'
RESOURCEGROUPNAME='az400m03l08-RG'
az group create -n $RESOURCEGROUPNAME -l $REGION
```

アプリサービスプランを作成する

SERVICEPLANNAME='az400m03l08-sp1'
az appservice plan create -g $RESOURCEGROUPNAME -n $SERVICEPLANNAME --sku S1

ユニークなアプリ名を持つ 2 つの Web アプリを作成します。

SUFFIX=$RANDOM$RANDOM
az webapp create -g $RESOURCEGROUPNAME -p $SERVICEPLANNAME -n RGATES$SUFFIX-DevTest
az webapp create -g $RESOURCEGROUPNAME -p $SERVICEPLANNAME -n RGATES$SUFFIX-Prod

注: DevTest Web アプリの名前を記録します。このラボで後ほど必要になります。

Web アプリサービスリソースのプロビジョニングプロセスが完了するのを待ってから、 [Cloud Shell] ペインを閉じます。

タスク 2: Application Insights リソースを構成する

Azure portal で、ページ上部の [リソース、サービス、ドキュメントの検索] テキストボックスを使用して「Application Insights」を検索し、結果のリストで [Application Insights] を選択します。
[Application Insights] ブレードで、 [+ 作成] を選択します。

[Application Insights] ウィンドウの [基本] タブで、次の設定を指定します (他の設定は既定値のままにします)。

設定	値
リソースグループ	az400m03l08-RG
Name	前のタスクで記録した DevTest Web アプリの名前
リージョン	前のタスクで Web アプリをデプロイしたのと同じ Azure リージョン

Review + create をクリックし、 [作成] をクリックします。
プロビジョニングプロセスが完了するまで待ちます。
Azure portal で、前のタスクで作成したリソースグループ az400m03l08-RG に移動します。
リソースのリストで、 [DevTest] Web アプリをクリックします。
[DevTest] Web アプリページの左側の垂直メニューの [監視] セクションで、[Application Insights] をクリックします。
[Application Insights] ウィンドウで、[Application Insights を有効にする] をクリックします。
[リソースの変更] セクションで、[既存のリソースの選択] オプションをクリックし、既存のリソースのリストで、新しく作成した Application Insight リソースを選択し、[適用] をクリックして、確認を求められたら [はい] をクリックします。
変更が有効になるまで待ちます。

注:ここでモニターアラートを作成します。これは、このラボの後半で使用します。
Web アプリ内の同じ [設定] / [Application Insights] メニューオプションから、 [Application Insights データの表示] を選びます。これにより、Azure Portal の [Application Insights] ブレードにリダイレクトされます。
[Application Insights リソース] ブレードの [監視] セクションで、 [アラート] をクリックし、 Create > Alert rule をクリックします。
[アラートルールの作成] ブレードの [条件] セクションで、[すべてのシグナルを表示] リンクをクリックし、「要求」と入力します。結果の一覧から [失敗した要求] を選びます。
[アラートルールの作成] ブレードの [条件] セクションで、 [しきい値] は [静的] に設定したままにして、次のように他の既定の設定を確認します。
- 集計の種類: Count
- 演算子:より大きい
- 単位:Count

[しきい値] テキストボックスに「0」と入力し、 [次へ: アクション] をクリックします。 [アクション] 設定ブレードでは変更を行わず、 [詳細] セクションで次のパラメーターを定義してください。

設定	値
重大度	2- 警告
アラートルール名	RGATESDevTest_FailedRequests
詳細オプション: アラートを自動的に解決する	オフ

注:メトリックアラートをルールがアクティブになるまでに最大 10 分かかる場合があります。

注:可用性 < 99%、サーバー応答時間 > 5 秒、サーバー例外 > 0など、さまざまなメトリックで複数のアラートルールを作成できます。

[確認と作成] をクリックしてアラートルールの作成を確認し、 [作成] をクリックしてもう一度確認します。アラートルールが正常に作成されるまで待ちます。

演習 2: リリースパイプラインを構成する

この演習では、リリースパイプラインを構成します。

タスク 1: リリースタスクを設定する

このタスクでは、リリースパイプラインの一部としてリリースタスクを設定します。

Azure DevOps ポータルの eShopOnWeb プロジェクトから、垂直ナビゲーションウィンドウの [パイプライン] を選び、 [パイプライン] セクション内の [リリース] をクリックします。
[新しいパイプライン] をクリックします。
[テンプレートの選択] ウィンドウで、 [Azure App Service の配置] を選択します (アプリケーションを Azure App Service に配置します。 Web App On Windows、Linux、コンテナー、関数アプリ、WebJobs から選択します) (テンプレートの [おすすめ] 一覧の下)。
[Apply] をクリックします。
表示された [ステージ] ウィンドウから、既定の “Stage 1” というステージ名を DevTest に更新します。 [X] ボタンを使ってポップアップウィンドウを閉じます。これで、リリースパイプラインのグラフィカルエディターに移動し、DevTest ステージが表示されます。
ページの上部で、現在のパイプラインの名前を New release pipeline から eshoponweb-cd に変更します。
DevTest ステージの上にマウスポインターを置き、 [複製] ボタンをクリックして DevTest ステージを追加のステージにコピーします。このステージの名前を Production に設定します。

注: 現在、パイプラインには、DevTest と運用という名前の 2 つのステージが含まれています。
[パイプライン] タブで、 [成果物の追加] 四角形を選び、 [ソース (ビルドパイプライン)] フィールドで eshoponweb-ci を選択します。 [追加] をクリックして、成果物の選択を確認します。
[成果物] 四角形で、 [継続的デプロイトリガー] (稲妻) に注目してください。これをクリックして、 [継続的配置トリガー] の設定を開きます。 [無効] をクリックし、スイッチを切り替えて有効にします。他のすべての設定をデフォルトのままにし、右上隅の [x] マークをクリックして、[継続的デプロイトリガー] ペインを閉じます。
[DevTest 環境] ステージ内で、[1 ジョブ、1 タスク] のラベルをクリックし、このステージ内のタスクを確認します。

注: DevTest 環境には、それぞれ成果物パッケージを Azure Web アプリに発行する 1 つのタスクがあります。
[すべてのパイプライン] > [eshoponweb-cd] ペインで、 [DevTest] ステージが選択されていることを確かめます。 [Azure サブスクリプション] ドロップダウンリストで、Azure サブスクリプションを選択し、[承認] をクリックします。プロンプトが表示されたら、Azure サブスクリプションの所有者ロールを持つユーザーアカウントを使用して認証します。
[アプリの種類] が [Web App on Windows] に設定されていることを確認します。次に、 [アプリサービス名] ドロップダウンリストで、 [DevTest] Web アプリの名前を選択します。
タスク [Deploy Azure App Service] (Azure App Service のデプロイ) を選択します。 [パッケージまたはフォルダー] フィールドで、既定値の “$(System.DefaultWorkingDirectory)/**/*.zip” を “$(System.DefaultWorkingDirectory)/**/Web.zip” に更新します

注: [タスク] タブの横に感嘆符が表示されます。これは、実稼働ステージ用の設定を構成する必要があるため、想定されるものです。
[アプリケーションと構成の設定] ウィンドウを開き、[アプリの設定] ボックスに「-UseOnlyInMemoryDatabase true -ASPNETCORE_ENVIRONMENT Development」と入力します。
[すべてのパイプライン] > [eshoponweb-cd] ウィンドウで、[パイプライン] タブに移動し、今度は [運用] ステージ内で、[1 個のジョブ、1 個のタスク] ラベルをクリックします。前の DevTest ステージと同様に、パイプラインの設定を完了します。 [タスク] タブ / [運用環境デプロイ] プロセスの [Azure サブスクリプション] ドロップダウンリストで、 [利用可能な Azure サービス接続] の下に表示される [DevTest 環境] ステージに使用した Azure サブスクリプションを選択します。これは、サブスクリプションの使用を承認する前にサービス接続を既に作成しているためです。
[アプリサービス名] ドロップダウンリストで、Prod Web アプリの名前を選択します。
タスク [Deploy Azure App Service] (Azure App Service のデプロイ) を選択します。 [パッケージまたはフォルダー] フィールドで、既定値の “$(System.DefaultWorkingDirectory)/**/*.zip” を “$(System.DefaultWorkingDirectory)/**/Web.zip” に更新します
[アプリケーションと構成の設定] ウィンドウを開き、[アプリの設定] ボックスに「-UseOnlyInMemoryDatabase true -ASPNETCORE_ENVIRONMENT Development」と入力します。
[すべてのパイプライン] > [eshoponweb-cd] ペインで、 [保存] をクリックし、 [保存] ダイアログボックスで [OK] をクリックします。

これで、リリースパイプラインが正常に構成されました。
eShopOnWeb プロジェクトが表示されているブラウザーウィンドウの垂直ナビゲーションウィンドウの [パイプライン] セクションで、 [パイプライン] をクリックします。
[パイプライン] ペインで、eshoponweb-ci ビルドパイプラインを表すエントリをクリックし、 [パイプラインの実行] をクリックします。
[パイプラインの実行] ペインで、既定の設定を受け入れ、[実行] をクリックしてパイプラインをトリガーします。 パイプラインのビルドが完了するまで待ちます。

注:ビルドが成功すると、リリースが自動的にトリガーされ、アプリケーションが両方の環境にデプロイされます。ビルドパイプラインが正常に完了したら、リリースアクションを検証します。
垂直ナビゲーションウィンドウの [パイプライン] セクションで [リリース] をクリックし、 [eshoponweb-cd] ペインで最新のリリースを表すエントリをクリックします。
[eshoponweb-cd] > [Release-1] ブレードで、リリースの進行状況を追跡し、両方の Web アプリへのデプロイが正常に完了したことを確認します。
Azure portal インターフェイスに切り替え、リソースグループ az400m03l08-RG に移動し、リソースのリストで [DevTest] Web アプリをクリックし、Web アプリブレードで [参照] をクリックして、Web ページ (eコマース Web サイト) が新しい Web ブラウザータブで正常に読み込まれることを確認します。
もう一度 Azure portal インターフェイスに切り替え、今度はリソースグループ az400m03l08-RG に移動し、リソースのリストで [実稼働] Web アプリをクリックし、Web アプリブレードで [参照] をクリックして、Web ページが新しい Web ブラウザータブで正常に読み込まれることを確認します。
EShopOnWeb Web サイトを表示している Web ブラウザータブを閉じます。

注:これで、CI/CD で構成されたアプリケーションができました。次の演習では、より高度なリリースパイプラインの一部として品質ゲートを設定します。

演習 3: リリースゲートを構成する

この演習では、リリースパイプラインに品質ゲートを設定します。

タスク 1: 承認用にデプロイ前ゲートを構成する

このタスクでは、デプロイ前ゲートを構成します。

Azure DevOps ポータルが表示されている Web ブラウザーのウィンドウに切り替えて、eShopOnWeb プロジェクトを開きます。垂直ナビゲーションウィンドウの [パイプライン] セクションで、 [リリース] をクリックし、 [eshoponweb-cd] ペインで [編集] をクリックします。
[すべてのパイプライン] > [eshoponweb-cd] ペインで、 [DevTest 環境] ステージを表す四角形の左端で、 [配置前の条件] を表す楕円形をクリックします。
[配置前の条件] ウィンドウで、[配置前の承認] スライダーを [有効] に設定し、[承認者] テキストボックスに Azure DevOps アカウント名を入力して選択します。

注: 実際のシナリオでは、これは自分の名前ではなく DevOps チーム名の別名にする必要があります。
事前承認の設定を [保存] し、ポップアップウィンドウを閉じます。
[リリースの作成] をクリックし、ポップアップウィンドウの [作成] ボタンを押して確認します。
“Release-2” が作成されたことを示す緑色の確認メッセージが表示されます。 “Release-2” のリンクをクリックして、その詳細に移動します。
[DevTest] ステージが [承認待ち] 状態であることに注目してください。 [承認] ボタンをクリックします。これにより、DevTest ステージがもう一度開始されます。

タスク 2: Azure Monitor のデプロイ後ゲートを構成する

このタスクでは、DevTest 環境のデプロイ後のゲートを有効にします。

[すべてのパイプライン] > [eshoponweb-cd] ペインに戻り、 [DevTest 環境] ステージを表す四角形の右端で、 [配置後の条件] を表す楕円形をクリックします。
[配置後の条件] ペインで、[ゲート] スライダーを [有効] に設定し、[+ 追加] をクリックして、ポップアップメニューで [Azure Monitor アラートのクエリ] をクリックします。
[デプロイ後の条件] ペインの [Azure Monitor アラートのクエリ] セクションの [Azure サブスクリプション] ドロップダウンリストで、Azure サブスクリプションへの接続を表すサービス接続エントリを選択し、 [リソースグループ] ドロップダウンリストで az400m03l08-RG エントリを選択します。
[デプロイ後の条件] ペインで、 [詳細] セクションを展開し、次のオプションを構成します。
- フィルターの種類: なし
- 重大度: Sev0、Sev1、Sev2、Sev3、Sev4
- 時間の範囲: 過去 1 時間
- アラートの状態: 確認済み、新規
- 監視条件: 起動済み
[配置後の条件] ペインで、[評価オプション] を展開して、次のオプションを構成します。
- ゲートの再評価間の時間の値を 5 分に設定します。
- ゲートが失敗するまでのタイムアウトの値を 8 分に設定します。
- [正常に実行されたゲートで、承認を求めます] オプションを選択します。
注:サンプリング間隔とタイムアウトは連携して機能するため、ゲートは適切な間隔で関数を呼び出し、タイムアウト期間内の同じサンプリング間隔で成功しなかった場合はデプロイを拒否します。
右上隅の [x] マークをクリックして、[配置後の条件] ペインを閉じます。
[すべてのパイプライン] > [eshoponweb-cd] ペインに戻り、 [保存] をクリックし、 [保存] ダイアログボックスで [OK] をクリックします。

演習 4: リリースゲートをテストする

この演習では、アプリケーションを更新してリリースゲートをテストします。これにより、デプロイがトリガーされます。

タスク 1:リリースゲートを追加した後、アプリケーションを更新しデプロイする

このタスクでは、最初に DevTest Web アプリ用のアラートをいくつか生成した後、リリースゲートを有効にしてリリースプロセスを追跡します。

Azure Portal から、先ほどデプロイした [DevTest Web アプリ] リソースを参照します。
[概要] ペインで、 [URL] フィールドに Web アプリケーションのハイパーリンクが表示されていることを確認します。このリンクをクリックすると、ブラウザーで eShopOnWeb Web アプリケーションにリダイレクトされます。
失敗した要求をシミュレートするには、URL に /discount を追加します。このようにすると、そのページが存在しないため、エラーメッセージが表示されます。このページを数回更新して、複数のイベントを生成します。
Azure portal の “リソース、サービス、ドキュメントの検索” フィールドに「Application Insights」と入力し、前の演習で作成した DevTest-AppInsights リソースを選択します。次に、 [アラート] に移動します。
結果の一覧には、重大度 2 の新しいアラートが少なくとも 1 つあるはずです。「Alerts」と入力して、Azure Monitor のアラートサービスを開きます。
一覧には、重大度 2 - 警告 の Failed_Alert が少なくとも 1 つあるはずです。これは、前の演習で存在しない Web サイトの URL アドレスを検証したときにトリガーされました。

注: アラートがまだ表示されない場合は、さらに数分待ってください。
Azure DevOps ポータルに戻り、eShopOnWeb プロジェクトを開きます。 [パイプライン] に移動し、 [リリース] 、 [eshoponweb-cd] の順に選択します。
[リリースの作成] ボタンをクリックします。
リリースパイプラインが開始されるのを待ち、DevTest ステージのリリースアクションを承認します。
DevTest リリースステージが正常に完了するまで待ちます。 デプロイ後ゲートが評価ゲートの状態に切り替わることがわかります。 評価ゲートのアイコンをクリックします。
[Azure Monitor アラートのクエリ] では、最初の失敗した状態が確認できます。
次の 5 分間、リリースパイプラインを保留中の状態にします。 5 分が経過した後、2 番目の評価が再び失敗することがわかります。
これは予期される動作です。DevTest Web アプリに対してトリガーされる Application Insights のアラートが存在するためです。

注:例外によってトリガーされるアラートがあるため、Query AzureMonitor ゲートは失敗します。これにより、本番環境への展開が妨げられます。
数分待ってから、リリースゲートの状態をもう一度検証します。リリースゲートが最初に確認され、最初の Application Insights アラートがアクション “起動済み” でトリガーされてから数分以内に、リリースゲートが正常に完了し、運用リリースステージのデプロイが許可されるはずです。

注: ゲートが失敗した場合は、アラートを閉じます。

[!IMPORTANT] 不要な料金が発生しないように、Azure portal で作成されたリソースを必ず削除してください。

確認

このラボでは、リリースパイプラインを構成してから、リリースゲートを構成してテストしました。

リリース ゲートを使用したデプロイの制御