デプロイ後にリソースをテストする

Bicep のデプロイを検証してプレビューすることで、Bicep ファイルが正常にデプロイされるという確信が得られました。 しかし、デプロイがすべてではありません。 デプロイの終了後、デプロイが期待通りに実行されたことを確認することも役に立ちます。

このユニットでは、デプロイの終了後に実行できるテストについて学習します。 また、期待どおりになっていない場合に行うデプロイのロールバックについても学習します。

スモーク テストとネガティブ テストを実行する

Bicep ファイルでリソースを定義する場合、Azure でリソースを作成することだけが目的ではありません。 組織の要件を満たしながら、組織の価値を高めることです。 Bicep ファイルを検証してプレビューすると、リソース定義が有効であるという確信が得られますが、必要な処理をリソースで実際に実行できるかどうかがわかるとは限りません。

たとえば、Bicep デプロイ パイプラインを使用して新しい Azure SQL 論理サーバーをデプロイするとします。 サーバーの Bicep 定義は有効で、リンターおよびプレフライト検証のステージを通過します。 what-if コマンドで、サーバーが作成されることが示されます。これは期待どおりです。 デプロイも正常に終了します。 しかし、それでもデプロイ プロセスの最後に、使用準備が整った稼働するデータベース サーバーが得られない場合があります。 次のような理由が考えられます。

• ネットワーク トラフィックがサーバーに到達できるようにファイアウォール規則を構成していません。
• サーバーで Microsoft Entra 認証を有効にすべきでない場合に有効にした、またはその逆。

基本的な Bicep ファイルをデプロイするだけの場合であっても、デプロイしたリソースが実際に機能し、要件を満たしていることをどのように検証するかは、検討に値します。 この検証を適用する方法の例を次に示します。

• Web サイトをデプロイするときは、パイプラインから Web アプリケーションに接続を試みます。 パイプラインから Web サイトに正常に接続でき、有効な応答コードが返されることを確認します。
• コンテンツ配信ネットワーク (CDN) をデプロイする場合は、CDN を介してリソースに接続を試みます。 パイプラインから CDN に正常に接続でき、有効な応答コードが返されることを確認します。

これらのテストは、"インフラストラクチャ スモーク テスト" と呼ばれることもあります。 スモーク テストは、デプロイの主要な問題を明らかにするように設計された単純な形式のテストです。

また、"ネガティブ テスト" を実行することもお勧めします。 否定テストは、リソースが望ましくない方法で動作しないことを確認するのに役立ちます。 たとえば、仮想マシンをデプロイするときには、Azure Bastion を使用して仮想マシンに安全に接続するのが推奨される方法です。 パイプラインにネガティブ テストを追加して、リモート デスクトップ接続や SSH を使用して仮想マシンに直接接続できないことを確認することができます。

Azure Pipelines からテストを実行する

パイプラインでテストを実行する方法はたくさんあります。 このモジュールでは、PowerShell を使用して記述されたテストを実行するオープンソース ツールである Pester を使用します。 他のテスト フレームワークを使用することや、テスト ツールを使用せずにテストを実行することもできます。 たとえば、考慮すべきもう 1 つのテスト ツールとして PSRule for Azure があります。これには、Azure 用に事前に構築された規則とテストが含まれています。 テンプレートの検証や、デプロイされた Azure リソースに対するテストも実行できます。 モジュールの概要に PSRule へのリンクがあります。

サポートされているテスト フレームワークを使用する場合、Azure Pipelines によって各テストの結果が認識されます。 パイプラインの実行情報と共にテスト結果が表示され、各テストの履歴が長期にわたって追跡されます。 次の演習では、インフラストラクチャ スモーク テストで Azure Pipelines を使用する方法について確認します。

ステップとステージ間でデータを渡す

パイプラインをステージに分割し、それぞれが独自の責任で行う場合、これらのステージ間でデータを渡す必要がある場合があります。 たとえば、あるステージで Azure リソースを作成し、別のステージでそれを操作する必要がある場合です。 データを渡すためには、作成されたリソースの名前を第 2 ステージが認識している必要があります。 たとえば、次の演習では、スモーク テスト ステージは、デプロイ ステージがデプロイするリソースにアクセスする必要があります。

Bicep ファイルによってリソースがデプロイされるので、そこからリソースのプロパティにアクセスし、デプロイの出力として発行することができます。 パイプラインでデプロイの出力にアクセスすることができます。 Azure Pipelines には、変数を発行してステージ間で使用できるようにするための特別な構文があります。

まず、パイプライン ステージの出力変数を発行する必要があります。 変数を出力するには、Azure Pipelines が読み取ることができるパイプライン ログに、特別に書式設定された文字列を書き込みます。 次の例では、myVariable という名前の変数に値 myValue が設定されています。

echo "##vso[task.setvariable variable=myVariable;isOutput=true]myValue"

Azure Pipelines により、パイプライン ログから文字列が読み取られ、解釈され、変数の値が出力として使用できるように処理されます。 この値を他のスクリプトと組み合わせて、Bicep のデプロイ出力の値をパイプライン ステージの出力変数として発行することができます。 このスクリプトを実行する方法については、次の演習で説明します。

次に、この変数をスモーク テスト ステージのジョブに使用できるようにする必要があります。 ジョブの変数を定義し、別の特別な形式の YAML 文字列を使用します。

- stage: SmokeTest
  jobs:
  - job: SmokeTest
    variables:
      myVariable: $[ stageDependencies.DeployStage.DeployJob.outputs['DeployJob.DeployStep.myVariable'] ]

これで、他の変数と同様に、スモーク テスト ジョブ内のすべてのステップから構文 myVariable を使用して $(myVariable) 値にアクセスできるようになります。 この変数は次の演習で使用します。

その他のテストの種類

機能テスト と 統合テスト は、多くの場合、デプロイされたリソースが期待どおりに動作することを検証するために使用されます。 たとえば、統合テストが Web サイトに接続し、テスト トランザクションを送信し、トランザクションが正常に完了したことを確認するまで待つ場合があります。 統合テストを使用すると、チームが構築したソリューションだけでなく、それが実行されているインフラストラクチャもテストすることができます。 今後のモジュールでは、これらの種類のテストをパイプラインに追加する方法について説明します。

また、パフォーマンス テストやセキュリティ侵入テストなど、他の種類のテストをデプロイ パイプラインから実行することもできます。 これらのテストについてはこのモジュールで説明しませんが、自動デプロイ プロセスの価値を高めることができます。

ロールバックまたはロールフォワード

パイプラインによるリソースのデプロイは成功しても、テストが失敗したとします。 この場合、何をする必要がありますか。

このモジュールの前半で、Azure Pipelines を使用すると、前のステージが失敗したときに実行される "ロールバック ステージ" を作成できることを学習しました。 このアプローチを使用して、テスト ステージで予期しない結果が報告されたときにロールバック ステージを作成することができます。 また、エラーが解決された一時的な問題によって発生したと思われる場合は、変更を手動でロールバックしたり、パイプライン全体を再実行したりすることもできます。

多くの場合、ロールバック ステージで実行すべきステップを実行するのは困難です。 一般的に、Bicep のデプロイは複雑であり、変更をロールバックするのは容易ではありません。 特に、デプロイに他のコンポーネントが含まれている場合は、ロールバックが困難になります。

たとえば、パイプラインで Azure SQL データベースを定義し、データベースにデータを追加する Bicep ファイルをデプロイするとします。 このデプロイをロールバックする場合、データを削除する必要はありますか。 データベースも削除する必要はありますか。 すべての失敗とすべてのロールバックが実行中の環境にどのように影響するかを予測するのは困難です。

そのため、多くの企業は "ロールフォワード" を好んでいます。つまり、失敗の理由をすぐに修正してから再度デプロイする処理です。 高品質の自動デプロイ プロセスを構築し、これらのラーニング パス全体で学習したすべてのベスト プラクティスに従うことで、問題をすばやく修正し、高品質を維持しながら Bicep ファイルを再デプロイすることができます。