Azure Pipelines を使用した CI/CD ベースライン アーキテクチャ

  • [アーティクル]

この記事では、Azure のステージングと運用の環境にアプリケーションの変更をデプロイするための高度な DevOps ワークフローについて説明します。 このソリューションでは、Azure Pipelines で継続的インテグレーション/継続的デプロイ (CI/CD) プラクティスを使用します。

重要

この記事では、Azure Pipelines を使用した一般的な CI/CD アーキテクチャについて説明します。 Azure App Service、Virtual Machines、Azure Power Platform など、さまざまな環境へのデプロイの詳細については取り上げません。 デプロイ プラットフォームの詳細については、別の記事で説明します。

アーキテクチャ

Azure Pipelines を使用した CI/CD パイプラインのアーキテクチャの図。

このアーキテクチャの Visio ファイルをダウンロードします。

注意

この記事では、アプリケーションの変更に関する CI/CD について説明しますが、Azure Pipelines を使用して、コードとしてのインフラストラクチャ (IaC) の変更用の CI/CD パイプラインを構築することもできます。

データフロー

このシナリオのデータ フローは次のとおりです。

  1. PR パイプライン - Azure Repos Git への pull request (PR) によって PR パイプラインがトリガーされます。 このパイプラインでは、高速の品質検査が実行されます。 これらの検査には以下が含まれます。

    • コードのビルド。依存関係管理システムから依存関係をプルする必要があります。
    • 静的コード分析、リンティング、セキュリティ スキャンなど、コードを分析するためのツールの使用
    • 単体テスト

    いずれかの検査が失敗した場合、パイプラインの実行は終了し、開発者は必要な変更を行う必要があります。 すべての検査に合格した場合、パイプラインには PR レビューが必要になります。 PR レビューが失敗した場合、パイプラインは終了し、開発者は必要な変更を行う必要があります。 すべてのチェックと PR レビューが成功すると、PR は正常にマージされます。

  2. CI パイプライン - Azure Repos Git へのマージによって CI パイプラインがトリガーされます。 このパイプラインでは、PR パイプラインと同じ検査が実行されますが、いくつかの重要な追加があります。 CI パイプラインでは統合テストが実行されます。 これらの統合検査では、ビルド成果物がまだ作成されていないため、ソリューションのデプロイは必要ありません。 これらの検査にはシークレットが必要なため、このパイプラインは Azure Key Vault からこれらのシークレットを取得します。 いずれかの検査が失敗した場合、パイプラインは終了し、開発者は必要な変更を行う必要があります。 このパイプラインが正常に実行された場合、結果としてビルド成果物が作成され発行されます。

  3. CD パイプライン トリガー - 成果物の発行によって CD パイプラインがトリガーされます。

  4. ステージングへの CD リリース - CD パイプラインは、CI パイプラインで作成されたビルド成果物をダウンロードし、ソリューションをステージング環境にデプロイします。 その後、パイプラインはステージング環境に対して受け入れテストを実行してデプロイを検証します。 受け入れテストが失敗した場合、パイプラインは終了し、開発者は必要な変更を行う必要があります。 テストが成功した場合は、手動検証タスクが実行され、個人またはグループがデプロイを検証してパイプラインを再開する必要があります。

  5. 運用環境への CD リリース - 手動介入が再開された場合、または手動による介入が実装されていない場合、パイプラインによってソリューションが運用環境にリリースされます。 パイプラインは、リリースが期待どおりに動作していることを確認するために、運用環境でスモーク テストを実行する必要があります。 手動介入ステップが取り消され、リリースが失敗した場合、またはスモーク テストが失敗した場合、リリースはロールバックされ、パイプラインは終了し、開発者は必要な変更を加える必要があります。

  6. Monitoring - Azure Monitor は、オペレーターが正常性、パフォーマンス、使用状況データを分析できるように、ログやメトリックなどの監視データを収集します。 Application Insights は、トレースなど、アプリケーション固有のすべての監視データを収集します。 Azure Log Analytics は、そのすべてのデータを格納するために使用されます。

コンポーネント

  • Azure Repos Git リポジトリは、コラボレーション プロジェクト用のバージョン管理とプラットフォームを提供するコード リポジトリとして機能します。

  • Azure Pipelines では、アプリケーション コードとインフラストラクチャ コードをビルド、テスト、パッケージ化、リリースする方法が提供されます。 この例には、次の役割を持つ 3 つの異なるパイプラインがあります。

    • PR パイプラインは、PR がリンティング、ビルド、単体テストを通じてマージできるようにする前にコードを検証します。
    • コードのマージ後に CI パイプラインが実行されます。 PR パイプラインと同じ検証を実行しますが、統合テストが追加され、すべてが成功した場合はビルド成果物を発行します。
    • CD パイプラインはビルド成果物をデプロイし、受け入れテストを実行し、運用環境にリリースします。

  • Azure 成果物フィードを使用すると、Maven、npm、NuGet などのソフトウェア パッケージを管理および共有できます。 成果物フィードを使用すると、パッケージのバージョン管理、昇格、廃止など、パッケージのライフサイクルを管理できます。 これにより、チームが最新かつ最も安全なバージョンのパッケージを使用していることを確認できます。

  • Key Vault では、シークレット、暗号化キー、証明書など、ソリューションのセキュリティで保護されたデータを管理する方法が提供されます。 このアーキテクチャでは、アプリケーション シークレットを格納するために使用されます。 これらのシークレットは、パイプラインを介してアクセスされます。 Azure Pipelines でシークレットにアクセスするには、Key Vault タスクを使用するか、キー コンテナーからシークレットをリンクします。

  • Monitor は、Azure サービスのメトリックやログ、アプリケーション テレメトリ、プラットフォーム メトリックを収集して格納する監視リソースです。 このデータは、アプリケーションを監視したり、アラートやダッシュボードを設定したり、障害の根本原因分析を実行したりするために使用します。

  • Application Insights は、Web アプリのパフォーマンスと使用状況に関するリアルタイムの分析情報を提供する監視サービスです。

  • Log Analytics ワークスペースは、Azure リソース、アプリケーション、サービスなど、複数のソースからのデータを保存、クエリ、分析できる一元的な場所を提供します。

代替

この記事では Azure Pipelines に焦点を当てていますが、次の代替手段も検討できます。

  • Azure DevOps Server (旧称 Team Foundation Server) をオンプレミスでの代替として使用できます。

  • Jenkins は、ビルドとデプロイを自動化するために使用されるオープンソース ツールです。

  • GitHub Actions では、GitHub から直接 CI/CD ワークフローを自動化できます。

  • GitHub リポジトリは、コード リポジトリとして置き換えることができます。 Azure Pipelines は GitHub リポジトリとシームレスに統合されます。

この記事では、Azure Pipelines での一般的な CI/CD プラクティスに焦点を当てます。 デプロイを検討できるコンピューティング環境のいくつかを次に示します。

  • App Services は、Web アプリ、REST API、およびモバイル バックエンドをホストするための HTTP ベースのサービスです。 お気に入りの言語で開発でき、アプリケーションは Windows ベースと Linux ベースの両方の環境で簡単に実行およびスケーリングできます。 Web Apps では、ステージングや運用などのデプロイ スロットがサポートされます。 アプリケーションをステージング スロットにデプロイし、運用スロットに解放できます。

  • Azure Virtual Machines では、細かな制御が必要なワークロード、または Web Apps では使用できない OS コンポーネントおよびサービス (Windows GAC、COM など) に依存するワークロードが処理されます。

  • Azure Power Platform は、ユーザーがインフラストラクチャや技術的な専門知識を必要とせずにアプリケーションを構築、デプロイ、管理できるようにするクラウド サービスのコレクションです。

  • Azure Functions は、アプリケーションのビルドに使用できるサーバーレス コンピューティング プラットフォームです。 Functions では、トリガーとバインドを使用して、サービスを統合できます。 Functions では、ステージングや運用などのデプロイ スロットもサポートされています。 アプリケーションをステージング スロットにデプロイし、運用スロットに解放できます。

  • Azure Kubernetes Service (AKS) は、Azure のマネージド Kubernetes クラスターです。 Kubernetes は、オープンソースのコンテナー オーケストレーション プラットフォームです。

  • Azure Container Apps を使用すると、サーバーレス プラットフォームでコンテナ化されたアプリケーションを実行できます。

シナリオの詳細

CI と CD プラクティスを使用して、アプリケーションまたはインフラストラクチャの変更をデプロイすると、次のようなさまざまな利点があります。

  • より短いリリース サイクル - 自動化された CI/CD プロセスを使用すると、手動のプラクティスよりも迅速にデプロイできます。 多くの組織では、1 日に複数回デプロイします。
  • コード品質の向上 - リンティングや単体テストなどの CI パイプラインの品質ゲートにより、より高品質なコードが得られます。
  • リリースのリスクの減少 - 適切な CI/CD プラクティスにより、新機能をリリースするリスクが大幅に減少します。 デプロイは、リリース前にテストできます。
  • 生産性の向上 - 自動化された CI/CD により、開発者は手動の統合とデプロイに取り組む必要がなくなり、新機能に集中できるようになります。
  • ロールバックを有効にする - 適切な CI/CD プラクティスにより、リリースされるバグまたは回帰の数は減りますが、引き続き発生します。 CI/CD では、以前のリリースへの自動ロールバックを有効にすることができます。

考えられるユース ケース

次のユースケースについて、Azure Pipelines および CI/CD プロセスを検討してください。

  • アプリケーション開発とそのライフサイクルを加速する。
  • 自動化されたビルドとリリースのプロセスで品質と一貫性を確保する。
  • アプリケーションの安定性と稼働時間を増やす。

考慮事項

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

オペレーショナル エクセレンス

  • インフラストラクチャを定義し、パイプラインにデプロイするには、 コードとしてのインフラストラクチャ (IaC) を実装することを検討してください。

  • VSTS マーケットプレースで使用できる トークン化タスク の 1 つを使用することを検討してください。コンテキストでは、多くの場合、機密情報 (API キー、パスワード、その他のシークレットなど) がデプロイまたは構成中にトークンまたはプレースホルダーに置き換えられるプロセスを参照します。

  • リリース定義で リリース変数 を使用して、環境の構成変更を推進します。 リリース変数は、リリース全体または特定の環境を対象にできます。 シークレット情報に変数を使用している場合は、必ず南京錠アイコンを選択します。

  • セキュリティで保護された仮想ネットワークで実行されているリソースにデプロイする場合は、セルフホステッド エージェントの使用を検討してください。 また、大量のビルドを実行している場合は、セルフホステッド エージェントを検討することもできます。 ビルド ボリュームが多い場合は、セルフホステッド エージェントを使用して、コスト効率の高い方法でビルドを高速化できます。

  • リリース パイプラインで Application Insights と他の監視ツールをできるだけ早く使用することを検討してください。 多くの組織は、運用環境でしか監視を開始しません。 他の環境を監視することにより、開発プロセスの早い段階でバグを発見し、運用環境で問題が発生するのを回避できます。

  • 運用環境に別個の監視リソースを使用することを検討してください。

  • クラシック インターフェイスの代わりに YAML パイプラインを使用することを検討してください。 YAML パイプラインは、他のコードと同様に扱うことができます。 たとえば、YAML パイプラインをソース管理にチェックインし、バージョン管理することができます。

  • YAML テンプレートを使用して、再利用を促進し、パイプラインを簡略化することを検討してください。 たとえば、PR パイプラインと CI パイプラインは似ています。 1 つのパラメーター化されたテンプレートを両方のパイプラインに使用できます。

  • 手動でのユーザー受け入れテスト、パフォーマンスとロード テスト、ロールバックなどのアクティビティをサポートするには、ステージングと運用環境以外の環境を作成することを検討してください。

コスト最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

Azure DevOps のコストは、アクセスを必要とする組織内のユーザーの数だけでなく、必要な同時実行ビルド/リリースの数やテスト ユーザーの数など、他の要因にも依存します。 詳しくは、「Azure DevOps の料金」をご覧ください。

この料金計算ツールでは、Azure DevOps を 20 ユーザーで実行する場合の見積もりが提供されます。

Azure DevOps はユーザー単位で 1 か月ごとに課金されます。 追加のテスト ユーザーまたはユーザー基本ライセンスに加えて、必要な同時実行パイプラインによっては追加料金が発生する場合があります。

セキュリティ

  • Microsoft ホステッドとセルフホステッドのどちらのエージェントを使用するかを選択する際は、Microsoft ホステッド エージェントを使用する場合のセキュリティ上の利点を考慮してください。

  • 環境に対するすべての変更がパイプラインを通じて行われるようにします。 最小限の特権の原則にロールベースのアクセス制御 (RBAC) を実装し、ユーザーが環境にアクセスできないようにします。

  • 依存関係を追跡し、ライセンスを管理し、脆弱性をスキャンし、依存関係を最新の状態に保つために、Azure Pipelines に手順を統合することを検討してください。

次のステップ

CI/CD および Azure DevOps の詳細については、次のリソースを参照してください。