クラシック リリース ゲートを使ったデプロイの制御

受講生用ラボ マニュアル

ラボの要件

ラボの概要

このラボでは、デプロイ ゲートの構成と、それらを使用して 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:ラボの前提条件の構成

注: 以前のラボでこのプロジェクトを既に作成している場合は、この演習をスキップできます。

この演習では、ラボの前提条件を設定します。これは、eShopOnWeb に基づくリポジトリを含む新しい Azure DevOps プロジェクトで構成されます。

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

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

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

    Create Project

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

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

  1. ラボ コンピューターのブラウザー ウィンドウで、Azure DevOps 組織と、前に作成した eShopOnWeb プロジェクトを開きます。 [リポジトリ] > [ファイル] 、 [リポジトリをインポートする] をクリックします。 [インポート] を選択します。 [Git リポジトリをインポートする] ウィンドウで、URL https://github.com/MicrosoftLearning/eShopOnWeb.git を貼り付けて、 [インポート] をクリックします。

    インポートリポジトリ

  2. リポジトリは次のように編成されています。

    • .ado フォルダーには、Azure DevOps の YAML パイプラインが含まれています。
    • .devcontainer フォルダーには、コンテナーを使って開発するためのセットアップが含まれています (VS Code でローカルに、または GitHub Codespaces で)。
    • infra フォルダーには、一部のラボ シナリオで使用される Bicep&ARM コードとしてのインフラストラクチャ テンプレートが含まれています。
    • .github フォルダーには、YAML GitHub ワークフローの定義が含まれています。
    • src フォルダーには、ラボ シナリオで使用される .NET 8 Web サイトが含まれています。

タスク 3: (既に終えている場合はスキップしてください) Azure DevOps で YAML を使用して CI パイプラインをコードとして構成する

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

  1. [パイプライン] ハブで [パイプライン] に戻ります。

  2. [最初のパイプラインを作成] ウィンドウで、[パイプラインの作成] をクリックします。

    注: ウィザードを使い、プロジェクトに基づいて新しい YAML パイプラインの定義を作成します。

  3. [コードはどこにありますか?] ペインで [Azure Repos Git (YAML)] オプションをクリックします。
  4. [リポジトリの選択] ペインで eShopOnWeb をクリックします。
  5. [パイプラインを構成する] ペインで、 [既存の Azure Pipelines YAML ファイル] を選びます。
  6. [既存の YAML ファイルを選択する] ペインで、次のパラメーターを指定します。
    • パス: .ado/eshoponweb-ci.yml
  7. [続行] をクリックして、これらの設定を保存します。
  8. [パイプライン YAML をレビューする] 画面で [実行] をクリックして、ビルド パイプライン プロセスを開始します。

  9. ビルド パイプラインが正常に完了するまで待ちます。 ソース コード自体に関する警告は無視します。これらは、このラボ演習には関係ありません。

    注:警告やエラーなど、YAML ファイルの各タスクをレビューできます。

  10. パイプラインには、プロジェクト名に基づく名前が付けられます。 パイプラインを識別しやすくするために、名前を変更しましょう。 [パイプライン] > [パイプライン] に移動し、先ほど作成したパイプラインをクリックします。 省略記号と [名前の変更または移動] オプションをクリックします。 eshoponweb-ci という名前を付け、 [保存] をクリックします。

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

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

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

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

  3. Bash または PowerShell の選択を求めるメッセージが表示されたら、[Bash] を選択します。

    注: Cloud Shell を初めて起動し、[ストレージがマウントされていません] というメッセージが表示された場合は、このラボで使用しているサブスクリプションを選択し、[ストレージの作成] を選択します。

  4. Bash プロンプトの [Cloud Shell] ペインで、次のコマンドを実行してリソース グループを作成します (<region> 変数プレースホルダーを 2 つの Azure Web アプリをホストする Azure リージョンの名前に置き換えます (たとえば、’westeurope’、’centralus’、またはその他の使用できる任意のリージョン))。

    注: 使用できる場所を確認するには、次のコマンドを実行します。<region> の [名前] を使います: az account list-locations -o table

    REGION='centralus'
RESOURCEGROUPNAME='az400m04l09-RG'
az group create -n $RESOURCEGROUPNAME -l $REGION

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

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

  6. ユニークなアプリ名を持つ 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 アプリの名前を記録します。 このラボで後ほど必要になります。

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

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

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

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

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

    注:非推奨メッセージは無視してください。 これは、このラボの後半で使用する継続的インテグレーション DevOps の有効化タスクの失敗を防ぐために必要です。

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

  11. 変更が有効になるまで待ちます。

    注:ここでモニター アラートを作成します。これは、このラボの後半で使用します。

  12. Web アプリ内の同じ [設定] / [Application Insights] メニュー オプションから、 [Application Insights データの表示] を選びます。 これにより、Azure Portal の [Application Insights] ブレードにリダイレクトされます。
  13. [Application Insights リソース] ブレードの [監視] セクションで、 [アラート] をクリックし、 Create > Alert rule をクリックします。
  14. [Select a signal] (シグナルの選択) ブレードの [シグナル名で検索] テキストボックスに「要求」と入力します。 結果の一覧から [失敗した要求] を選びます。

  15. [アラート ルールの作成] ブレードの [条件] セクションで、 [しきい値] は [静的] に設定したままにして、次のように他の既定の設定を確認します。

    • 集計の種類: Count
    • 演算子:より大きい
    • 単位:Count

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

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

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

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

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

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

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

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

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

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

  7. DevTest ステージの上にマウス ポインターを置き、 [複製] ボタンをクリックして DevTest ステージを追加のステージにコピーします。 このステージに Production という名前を付けます。

    注: 現在、パイプラインには、DevTest と運用という名前の 2 つのステージが含まれています。

  8. [パイプライン] タブで、 [成果物の追加] 四角形を選び、 [ソース (ビルド パイプライン)] フィールドで eshoponweb-ci を選択します。 [追加] をクリックして、成果物の選択を確認します。
  9. [成果物] 四角形で、 [継続的デプロイ トリガー] (稲妻) に注目してください。 これをクリックして、 [継続的配置トリガー] の設定を開きます。 [無効] をクリックし、スイッチを切り替えて有効にします。 他のすべての設定をデフォルトのままにし、右上隅の [x] マークをクリックして、[継続的デプロイ トリガー] ペインを閉じます。

  10. [DevTest 環境] ステージ内で、[1 ジョブ、1 タスク] のラベルをクリックし、このステージ内のタスクを確認します。

    注: DevTest 環境には、それぞれ成果物パッケージを Azure Web アプリに発行する 1 つのタスクがあります。

  11. [すべてのパイプライン] > [eshoponweb-cd] ペインで、 [DevTest] ステージが選択されていることを確かめます。 [Azure サブスクリプション] ドロップダウン リストで、Azure サブスクリプションを選択し、[承認] をクリックします。 プロンプトが表示されたら、Azure サブスクリプションの所有者ロールを持つユーザー アカウントを使用して認証します。
  12. [アプリの種類] が [Web App on Windows] に設定されていることを確認します。 次に、 [アプリ サービス名] ドロップダウン リストで、 [DevTest] Web アプリの名前を選択します。

  13. タスク [Deploy Azure App Service] (Azure App Service のデプロイ) を選択します。 [パッケージまたはフォルダー] フィールドで、既定値の “$(System.DefaultWorkingDirectory)/**/*.zip” を “$(System.DefaultWorkingDirectory)/**/Web.zip” に更新します

    [タスク] タブの横に感嘆符が表示されます。これは、運用ステージ用の設定を構成する必要があるため、予期されるものです。

  14. [アプリケーションと構成の設定] ウィンドウを開き、[アプリの設定] ボックスに「-UseOnlyInMemoryDatabase true -ASPNETCORE_ENVIRONMENT Development」と入力します。

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

  19. [すべてのパイプライン] > [eshoponweb-cd] ペインで、 [保存] をクリックし、 [保存] ダイアログ ボックスで [OK] をクリックします。

    これで、リリース パイプラインが正常に構成されました。

  20. eShopOnWeb プロジェクトが表示されているブラウザー ウィンドウの垂直ナビゲーション ウィンドウの [パイプライン] セクションで、 [パイプライン] をクリックします。
  21. [パイプライン] ペインで、eshoponweb-ci ビルド パイプラインを表すエントリをクリックし、 [パイプラインの実行] をクリックします。

  22. [パイプラインの実行] ペインで、既定の設定を受け入れ、[実行] をクリックしてパイプラインをトリガーします。 パイプラインのビルドが完了するまで待ちます。

    注:ビルドが成功すると、リリースが自動的にトリガーされ、アプリケーションが両方の環境にデプロイされます。 ビルド パイプラインが正常に完了したら、リリース アクションを検証します。

  23. 垂直ナビゲーション ウィンドウの [パイプライン] セクションで [リリース] をクリックし、 [eshoponweb-cd] ペインで最新のリリースを表すエントリをクリックします。
  24. [eshoponweb-cd] > [Release-1] ブレードで、リリースの進行状況を追跡し、両方の Web アプリへのデプロイが正常に完了したことを確認します。
  25. Azure portal インターフェイスに切り替え、リソース グループ az400m04l09-RG に移動し、リソースのリストで [DevTest] Web アプリをクリックし、Web アプリ ブレードで [参照] をクリックして、Web ページ (eコマース Web サイト) が新しい Web ブラウザー タブに正常に読み込まれることを確認します。
  26. もう一度 Azure portal インターフェイスに切り替え、今度はリソース グループ az400m04l09-RG に移動し、リソースのリストで運用 Web アプリをクリックし、Web アプリ ブレードで [参照] をクリックして、Web ページが新しい Web ブラウザー タブに正常に読み込まれることを確認します。

  27. EShopOnWeb Web サイトを表示している Web ブラウザー タブを閉じます。

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

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

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

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

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

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

  3. [配置前の条件] ウィンドウで、[配置前の承認] スライダーを [有効] に設定し、[承認者] テキスト ボックスに Azure DevOps アカウント名を入力して選択します。

    注: 実際のシナリオでは、これは自分の名前ではなく DevOps チーム名の別名にする必要があります。

  4. 事前承認の設定を [保存] し、ポップアップ ウィンドウを閉じます。
  5. [リリースの作成] をクリックし、ポップアップ ウィンドウの [作成] ボタンを押して確認します。
  6. “Release-2” が作成されたことを示す緑色の確認メッセージが表示されます。 “Release-2” のリンクをクリックして、その詳細に移動します。
  7. [DevTest] ステージが [承認待ち] 状態であることに注目してください。 [承認] ボタンをクリックします。 これにより、DevTest ステージがもう一度開始されます。

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

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

  1. [すべてのパイプライン] > [eshoponweb-cd] ペインに戻り、 [DevTest 環境] ステージを表す四角形の右端で、 [配置後の条件] を表す楕円形をクリックします。
  2. [配置後の条件] ペインで、[ゲート] スライダーを [有効] に設定し、[+ 追加] をクリックして、ポップアップ メニューで [Azure Monitor アラートのクエリ] をクリックします。
  3. [デプロイ後の条件] ペインの [Azure Monitor アラートのクエリ] セクションの [Azure サブスクリプション] ドロップダウン リストで、Azure サブスクリプションへの接続を表すサービス接続エントリを選択し、 [リソース グループ] ドロップダウン リストで、az400m04l09-RG エントリを選択します。

  4. [デプロイ後の条件] ペインで、 [詳細] セクションを展開し、次のオプションを構成します。

    • フィルターの種類: なし
    • 重大度: Sev0、Sev1、Sev2、Sev3、Sev4
    • 時間の範囲: 過去 1 時間
    • アラートの状態: 確認済み、新規
    • 監視条件: 起動済み

  5. [配置後の条件] ペインで、[評価オプション] を展開して、次のオプションを構成します。

    • ゲートの再評価間の時間の値を 5 分に設定します。
    • ゲートが失敗するまでのタイムアウトの値を 8 分に設定します。
    • [正常に実行されたゲートで、承認を求めます] オプションを選択します。

    注:サンプリング間隔とタイムアウトは連携して機能するため、ゲートは適切な間隔で関数を呼び出し、タイムアウト期間内の同じサンプリング間隔で成功しなかった場合はデプロイを拒否します。

  6. 右上隅の [x] マークをクリックして、[配置後の条件] ペインを閉じます。
  7. [すべてのパイプライン] > [eshoponweb-cd] ペインに戻り、 [保存] をクリックし、 [保存] ダイアログ ボックスで [OK] をクリックします。

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

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

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

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

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

  6. 一覧には、重大度 2 - 警告 の Failed_Alert が少なくとも 1 つあるはずです。 これは、前の演習で存在しない Web サイトの URL アドレスを検証したときにトリガーされました。

    注: アラートがまだ表示されない場合は、さらに数分待ってください。

  7. Azure DevOps ポータルに戻り、eShopOnWeb プロジェクトを開きます。 [パイプライン] に移動し、 [リリース] 、 [eshoponweb-cd] の順に選択します。
  8. [リリースの作成] ボタンをクリックします。
  9. リリース パイプラインが開始されるのを待ち、DevTest ステージのリリース アクションを承認します。
  10. DevTest リリース ステージが正常に完了するまで待ちます。 デプロイ後ゲートが評価ゲートの状態に切り替わることがわかります。 評価ゲートのアイコンをクリックします。
  11. [Azure Monitor アラートのクエリ] では、最初の失敗した状態が確認できます。
  12. 次の 5 分間、リリース パイプラインを保留中の状態にします。 5 分が経過した後、2 番目の評価が再び失敗することがわかります。

  13. これは予期される動作です。DevTest Web アプリに対してトリガーされる Application Insights のアラートが存在するためです。

    注:例外によってトリガーされるアラートがあるため、Query AzureMonitor ゲートは失敗します。 これにより、本番環境への展開が妨げられます。

  14. 数分待ってから、リリース ゲートの状態をもう一度検証します。 リリース ゲートが最初に確認され、最初の Application Insights アラートがアクション “起動済み” でトリガーされてから数分以内に、リリース ゲートが正常に完了し、運用リリース ステージのデプロイが許可されるはずです。

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

演習 6: Azure ラボ リソースを削除する

この演習では、このラボでプロビジョニングした Azure リソースを削除し、予期しない料金を排除します。

注:新規に作成し、使用しなくなったすべての Azure リソースを削除することを忘れないでください。 使用していないリソースを削除することで、予期しない料金が発生しなくなります。

タスク 1:Azure ラボ リソースを削除する

このタスクでは、Azure Cloud Shell を使用して、このラボでプロビジョニングされた Azure リソースを削除し、不要な料金を排除します。

  1. Azure portal で、Cloud Shell ウィンドウ内で Bash シェル セッションを開きます。

  2. 次のコマンドを実行して、このモジュールのラボ全体で作成したすべてのリソース グループのリストを表示します。

    az group list --query "[?starts_with(name,'az400m04l09-RG')].name" --output tsv

  3. 次のコマンドを実行して、このモジュールのラボ全体を通して作成したすべてのリソース グループを削除します。

    az group list --query "[?starts_with(name,'az400m04l09-RG')].[name]" --output tsv | xargs -L1 bash -c 'az group delete --name $0 --no-wait --yes'

    注:コマンドは非同期に実行されるので (–nowait パラメーターで決定される)、同じ Bash セッション内ですぐに別の Azure CLI コマンドを実行できますが、リソース グループが実際に削除されるまでに数分かかります。

確認

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