次の方法で共有

Azure ランディング ゾーン用のテスト駆動開発

  • [アーティクル]

テスト駆動開発 (TDD) は、コードベースのソリューションの新機能と改善の質を向上させる、ソフトウェア開発および DevOps プロセスです。 TDD は、実際のコードを開発する前に単体テスト ケースを作成し、テスト ケースに対してコードをテストします。 このアプローチは、最初にコードを開発し、後でテスト ケースを作成するのとは対照的です。

ランディング ゾーンは、コードを使用して事前プロビジョニングされたワークロードをホストするための環境です。 ランディング ゾーンには、定義された一連のクラウド サービスとベスト プラクティスを使用する基本的な機能が含まれます。 この記事では、品質、セキュリティ、運用、ガバナンスの要件を満たしながら、TDD を使用して成功したランディング ゾーンをデプロイするアプローチについて説明します。

クラウド インフラストラクチャは、コード実行の出力です。 適切に構造化、テスト、および検証されたコードにより、実行可能なランディング ゾーンが生成されます。 クラウドベースのインフラストラクチャとその基盤となるソース コードは、このアプローチを使用して、ランディング ゾーンが高品質であり、コア要件を満たしていることを保証できます。

このアプローチを使用して、初期開発時の単純な機能要求を満たします。 クラウド導入ライフサイクルの後半で、このプロセスを使用して、セキュリティ、運用、ガバナンス、またはコンプライアンスの要件を満たすことができます。 このプロセスは、並列開発作業でランディング ゾーンを開発およびリファクタリングする場合に特に役立ちます。

テスト駆動開発サイクル

次の図は、Azure ランディング ゾーンのテスト駆動開発サイクルを示しています。

Azure ランディング ゾーンのテスト駆動開発サイクルの図。

  1. テストの作成。 機能の受け入れ基準が満たされていることを検証するためのテストを定義します。 開発時にテストを自動化して、特にエンタープライズ規模のデプロイで手動テスト作業の量を減らします。

  2. ランディング ゾーンのテスト。 新しいテストと既存のテストを実行します。 必要な機能がクラウド プロバイダーのオファリングに含まれず、以前の開発作業によって提供されていない場合、テストは失敗します。 既存のテストを実行すると、新しい機能またはテストによって既存のランディング ゾーン機能の信頼性が低下しないことを検証するのに役立ちます。

  3. ランディング ゾーンの展開とリファクタリング。 要求された付加価値機能を満たすようにソース コードを追加または変更し、コード ベースの全般的な品質を改善します。

    TDD 基準を満たすために、クラウド プラットフォーム チームは、要求された機能を満たすコードのみを追加します。 ただし、コードの品質とメンテナンスは共有作業です。 クラウド プラットフォーム チームは、新機能の要求を満たすため、重複を取り除いてコードを明確にして、コードの改善に努める必要があります。 新しいコードを作成してからソース コードをリファクタリングするまでの間にテストを実行することを強くお勧めします。

  4. ランディング ゾーンのデプロイ。 ソース コードが機能の要求を満たすようになったら、制御されたテストまたはサンドボックス環境で、変更されたランディング ゾーンをクラウド プロバイダーにデプロイします。

  5. ランディング ゾーンのテスト。 ランディング ゾーンを再テストして、新しいコードが要求された機能の受け入れ基準を満たしていることを検証します。 すべてのテストに合格すると、この機能は完成したと見なされ、受け入れ基準が満たされていると見なされます。

TDD サイクルは、"完成の定義" を完全に満たすまで、上記の基本的な手順を繰り返します。 すべての付加価値機能と受け入れ基準が関連するテストに合格したら、ランディング ゾーンはクラウド導入計画の次のウェーブをサポートする準備ができています。

TDD を効果的にするサイクルは、"赤/緑テスト" と呼ばれることがよくあります。 このアプローチでは、クラウド プラットフォーム チームは、完成の定義と定義された受け入れ基準に基づいて、不合格のテスト (赤テスト) から開始します。 クラウド プラットフォーム チームは、機能または受け入れ基準ごとに、テストに合格する (緑テスト) まで開発タスクを実行します。

TDD の目標は、一連のテストを作成することではなく、より優れた設計に取り組むことです。 テストは、プロセスを完了するための貴重な成果物です。

完了の定義

成功は、ランディング ゾーンの開発またはリファクタリング中に、クラウド プラットフォーム チームに実用的な情報をほとんど提供しない主観的な尺度です。 明確さの欠如は、クラウド環境における期待と脆弱性の見逃しにつながる可能性があります。 クラウド プラットフォーム チームは、ランディング ゾーンをリファクタリングまたは展開する前に、各ランディング ゾーンの "完成の定義" (DoD) について明確にしておく必要があります。

DoD は、ランディング ゾーンの開発作業に含める期待される付加価値機能を定義する、クラウド プラットフォーム チームと他の影響を受けるチームとの間の簡単な合意です。 DoD は多くの場合、短期間のクラウド導入計画に沿ったチェックリストです。

チームが採用するワークロードとクラウド機能が増えるにつれて、DoD と受け入れ基準はより複雑になります。 成熟したプロセスでは、期待される機能にはそれぞれ独自の受け入れ基準があり、より明確になります。 付加価値機能がすべて受け入れ基準を満たしている場合、ランディング ゾーンは、現在の導入の高まりやリリースの成功を可能にするように十分に構成されています。

単純な DoD の例

最初の移行作業では、DoD が過度に単純な場合があります。 次は、単純な DoD の例です。

初期ランディング ゾーンは、初期学習のために 10 個のワークロードをホストします。 これらのワークロードはビジネスにとって重要ではなく、機密データにはアクセスできません。 将来的には、これらのワークロードはおそらく運用環境にリリースされますが、重要度と機密性は変わらないと予想されます。

これらのワークロードをサポートするために、クラウド導入チームは次の条件を満たす必要があります。

  • 提案されたネットワーク設計に合わせたネットワークのセグメント化。 このような環境は、パブリック インターネットにアクセスできる境界ネットワークである必要があります。
  • デジタル資産の検出に合わせたワークロードをホストするための、コンピューティング、ストレージ、およびネットワーク リソースへのアクセス。
  • 使いやすさを向上させるためのスキーマの名前付けとタグ付け。
  • 導入中、クラウド導入チームがサービス構成を変更するための一時的なアクセス。
  • 運用リリースの前に、運用管理のための継続的な ID とアクセスを管理するための企業の ID プロバイダーとの統合。 その時点で、クラウド導入チームのアクセス権を取り消す必要があります。

最後の点は機能や受け入れ基準ではありませんが、より多くの拡張が必要となり、他のチームと早期に調査する必要があることを示す指標です。

より複雑な DoD の例

クラウド導入フレームワーク内の管理方法は、ガバナンス チームの自然な成熟度を物語る体験を提供します。 この体験に組み込まれているのは、ポリシー ステートメントの形式での DoD と受け入れ基準のいくつかの例です。

前の例は、ランディング ゾーンの DoD を策定するのに役立つ基本的なサンプルです。 クラウド ガバナンスの 5 つの規範のそれぞれについてサンプル ポリシーを取得できます。

ランディング ゾーンの TDD をサポートするための Azure ツールと機能

次の図は、Azure で使用可能なテスト駆動開発ツールを示しています。

Azure で使用可能なテスト駆動開発ツールの図。

ランディング ゾーンを作成するために、これらの Azure のツールと機能を TDD に簡単に統合できます。 これらのツールは特定の目的に対応しているため、TDD サイクルに合わせてランディング ゾーンを簡単に開発、テスト、デプロイできます。

  • Azure Resource Manager は、ビルドとデプロイのプロセスに一貫したプラットフォームを提供します。 Resource Manager プラットフォームでは、ソース コード定義に基づいてランディング ゾーンをデプロイできます。

  • Azure Resource Managerr (ARM) テンプレートは、Azure にデプロイされている環境の主要なソース コードを提供します。 Terraform などの一部のサードパーティ製のツールは、Azure Resource Manager に送信するための独自の ARM テンプレートを提供します。

  • Azure クイックスタート テンプレートには、ランディング ゾーンとワークロードのデプロイの迅速化に役立つソース コードのテンプレートが用意されています。

  • Azure Policy には、DoD で受け入れ基準をテストするための主要なメカニズムが用意されています。 Azure Policy を使用すると、デプロイがガバナンス ポリシーから逸脱した場合に、自動化された検出、保護、解決を提供することもできます。

    TDD サイクルでは、単一の受け入れ基準をテストするためのポリシー定義を作成できます。 Azure Policy には、DoD 内の個々の受け入れ基準を満たすことができる組み込みのポリシー定義が含まれています。 このアプローチは、ランディング ゾーンを変更する前に赤テストのメカニズムを提供します。

    Azure Policy には、ランディング ゾーンに完全な DoD をテストして適用するために使用できる組み込みのポリシー イニシアティブも含まれています。 すべての受け入れ基準をサブスクリプション全体に割り当てられたポリシー イニシアティブに追加できます。 ランディン グゾーンが DoD を満たすと、Azure Policy はテスト基準を適用して、将来のリリースでテストが失敗する原因となる可能性のあるコードの変更を回避できます。

    TDD アプローチの一環として、コードとしての Azure Policy を設計および確認します。

  • Azure Resource Graph には、ランディング ゾーン内にデプロイされた資産に関する情報に基づいて、データ ドリブン テストを作成するためのクエリ言語が用意されています。 このツールでは、後で導入計画の中で、ワークロード資産と基になるクラウド環境との間の相互作用に基づいて、複雑なテストを定義することもできます。

    Resource Graph には高度なクエリのサンプルが含まれていて、高度なテスト シナリオ用にランディング ゾーン内にワークロードをデプロイする方法を理解するために使用できます。

好みの方法に応じて、次のツールを使用することもできます。

次の手順