この記事では、Azure Pipelinesを使用して継続的インテグレーションおよび継続的デプロイ (CI/CD) パイプラインを構築するためのベースライン アーキテクチャについて説明します。 Azureのステージング環境と運用環境へのアプリケーションのビルド、テスト、デプロイを自動化する必要がある場合は、このアーキテクチャを出発点として使用します。 このアーキテクチャでは、プル要求 (PR)、継続的インテグレーション (CI)、継続的デプロイ (CD) の 3 つのパイプラインを定義し、Azure Repos、Azure Key Vault、Azure Monitorと連携してアプリを安全に検証、ビルド、デプロイする方法を示します。
Architecture
このアーキテクチャの Visio ファイル をダウンロードします。
注
この記事では、アプリケーションの変更に関する CI/CD について説明しますが、Azure Pipelines を使用して、コード (IaC) の変更としてのインフラストラクチャ用の CI/CD パイプラインを構築することもできます。
データフロー
このシナリオのデータ フローは次のとおりです。
PR パイプライン - Azure Repos Git へのプル要求 (PR) によって PR パイプラインがトリガーされます。 このパイプラインは、高速品質チェックを実行します。 これらのチェックには、次のものが含まれている必要があります。
- 依存関係管理システムから依存関係をプルする必要があるコードをビルドする。
- 静的コード分析、リンティング、セキュリティ スキャンなど、コードを分析するためのツールの使用
- 単体テスト
いずれかのチェックが失敗した場合、パイプラインの実行は終了し、開発者は必要な変更を行う必要があります。 すべての検査に合格した場合、パイプラインには PR レビューが必要になります。 PR レビューが失敗した場合、パイプラインは終了し、開発者は必要な変更を行う必要があります。 すべてのチェックと PR レビューに合格すると、PR は正常にマージされます。
CI パイプライン - Azure Repos Git へのマージによって CI パイプラインがトリガーされます。 このパイプラインは、PR パイプラインと同じチェックと統合テストを実行します。 CI パイプラインでは、次の 2 つの理由から、PR パイプラインの代わりに統合テストが実行されます。
- 統合テストはリソースを大量に消費する可能性があるため、マージ後にそれらを実行すると、開発速度とバグ検出のバランスが取られます。
- PRでテストに合格していても、マージ後も合格するとは限りません。というのも、メインブランチへの変更によって、マージ後のテストでしか検出できない新たな問題が発生する可能性があるためです。
ビルド成果物はまだ作成されていないため、これらの統合テストではソリューションをデプロイする必要はありません。 テストでシークレットが必要な場合、パイプラインはAzure Key Vaultからそれらを取得します。 チェックが失敗した場合、パイプラインは終了し、開発者は必要な変更を行う必要があります。 このパイプラインを正常に実行すると、ビルド成果物が作成され、発行されます。
CD パイプライン トリガー - 成果物の発行によって CD パイプラインがトリガーされます。
ステージングへの CD リリース - CD パイプラインは、CI パイプラインで作成されたビルド成果物をダウンロードし、ソリューションをステージング環境にデプロイします。 その後、パイプラインはステージング環境に対して受け入れテストを実行してデプロイを検証します。 受け入れテストが失敗した場合、パイプラインは終了し、開発者は必要な変更を行う必要があります。 テストが成功した場合は、 手動検証タスク を実装して、ユーザーまたはグループにデプロイの検証とパイプラインの再開を要求できます。
運用環境への CD リリース - 手動による介入が再開された場合、または手動による介入が実装されていない場合、パイプラインによってソリューションが運用環境にリリースされます。 パイプラインでは、リリースが期待どおりに動作していることを確認するために、運用環境でスモーク テストを実行する必要があります。 手動介入ステップによってキャンセル、リリースが失敗、またはスモーク テストが失敗した場合、リリースはロールバックされ、パイプラインが終了し、開発者は必要な変更を行う必要があります。
監視 - Azure Monitor は、オペレーターが正常性、パフォーマンス、使用状況データを分析できるように、ログやメトリックなどの監視データを収集します。 Application Insights では、トレースなど、アプリケーション固有のすべての監視データが収集されます。 Azure Log Analytics は、そのすべてのデータを格納するために使用されます。
Components
Azure Repos Git リポジトリは、バージョン管理とコラボレーション プロジェクトのプラットフォームを提供するコード リポジトリとして機能します。
Azure Pipelines には、アプリケーションとインフラストラクチャのコードをビルド、テスト、パッケージ化、リリースする方法が用意されています。 この例には、次の役割を持つ 3 つの異なるパイプラインがあります。
- PR パイプラインは、PR がリンティング、ビルド、および単体テストを通じてマージできるようにする前にコードを検証します。
- CI パイプラインは、コードがマージされた後に実行されます。 PR パイプラインと同じ検証を実行しますが、すべてが成功した場合は統合テストを追加し、ビルド成果物を発行します。
- CD パイプラインでは、ビルド成果物のデプロイ、受け入れテストの実行、運用環境へのリリースが行われます。
Azure Artifacts フィードを使用すると、Maven、npm、NuGet などのソフトウェア パッケージを管理および共有できます。 フィードを使用すると、パッケージのバージョン管理、昇格、廃止など、パッケージのライフサイクルを管理できます。これにより、チームが最新かつ最も安全なバージョンの依存関係を確実に使用できるようになります。
Key Vault には、シークレット、暗号化キー、証明書など、ソリューションのセキュリティで保護されたデータを管理する方法が用意されています。 このアーキテクチャでは、アプリケーション シークレットを格納するために使用されます。 これらのシークレットには、パイプライン経由でアクセスされます。 シークレットにアクセスするには、Azure Pipelines で Key Vault タスク を使用するか、 Key Vault からシークレットをリンクします。
Monitor は、Azure サービスのメトリックとログ、アプリケーション テレメトリ、プラットフォーム メトリックを収集して格納する可観測性リソースです。 このデータを使用して、アプリケーションの監視、アラート、ダッシュボードの設定、障害の根本原因分析の実行を行います。
Application Insights は、Web アプリケーションのパフォーマンスと使用状況に関するリアルタイムの分析情報を提供する監視サービスです。
Log Analytics ワークスペース は、Azure リソース、アプリケーション、サービスなど、複数のソースからのデータを格納、クエリ、分析できる中心的な場所です。
Alternatives
この記事では Azure Pipelines に焦点を当てていますが、次の代替手段を検討できます。
Azure DevOps Server は 、オンプレミスの代替として使用できます。
Jenkins は、ビルドとデプロイを自動化するために使用されるオープン ソース ツールです。
GitHub Actions を使用すると、GitHub から直接 CI/CD ワークフローを自動化できます。
GitHub リポジトリ は、コード リポジトリとして置き換えることができます。 Azure Pipelines は GitHub リポジトリとシームレスに統合されます。
この記事では、Azure Pipelines での一般的な CI/CD プラクティスについて説明します。 デプロイを検討できるコンピューティング環境を次に示します。
App Service は、Web アプリケーション、REST API、モバイル バックエンドをホストするための HTTP ベースのサービスです。 お気に入りの言語で開発でき、アプリケーションは Windows ベースと Linux ベースの両方の環境で簡単に実行およびスケーリングできます。 App Service では、ステージングや運用などのデプロイ スロットがサポートされているため、アプリケーションをステージング スロットにデプロイし、運用スロットにリリースできます。
Azure 仮想マシンは、高度な制御が必要なワークロード、または App Service では不可能な OS コンポーネントとサービスに依存するワークロードを処理します。
Azure Power Platform は、インフラストラクチャや技術的な専門知識を必要とせずに、ユーザーがアプリケーションを構築、デプロイ、管理できるようにするクラウド サービスのコレクションです。
Azure 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) を実装することを検討してください。
リリース定義で リリース変数 を使用して、環境の構成変更を促進します。 リリース変数のスコープは、リリース全体または特定の環境に設定できます。 シークレット情報に変数を使用する場合は、必ず南京錠アイコンを選択してください。
セキュリティで保護された仮想ネットワークで実行されているリソースにデプロイする場合、または大量のビルドを実行する場合は、 セルフホステッド エージェント の使用を検討してください。 セルフホステッド エージェントは、コスト効率の高い方法で大規模にビルドを高速化するのに役立ちます。
リリース パイプラインでは 、できるだけ早く Application Insights やその他の監視ツールを使用することを検討してください。 多くの組織は、運用環境でのみ監視を開始します。 他の環境を監視することで、開発プロセスの早い段階でバグを特定し、運用環境の問題を回避できます。
運用環境に個別の監視リソースを使用することを検討してください。
クラシック インターフェイスの代わりに YAML パイプライン を使用することを検討してください。 YAML パイプラインは、他のコードと同様に扱うことができます。 たとえば、YAML パイプラインをソース管理にチェックインし、バージョン管理することができます。
YAML テンプレートを使用して再利用を促進し、パイプラインを簡略化することを検討してください。 たとえば、PR パイプラインと CI パイプラインは似ています。 1 つのパラメーター化されたテンプレートを両方のパイプラインに使用できます。
手動ユーザー受け入れテスト、パフォーマンスとロード テスト、ロールバックなどのアクティビティをサポートするために、ステージングと運用環境以外の環境を作成することを検討してください。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、 コスト最適化の柱の概要を参照してください。
Azure DevOps のコストは、アクセスを必要とする組織内のユーザーの数と、必要な同時ビルド/リリースの数やテスト ユーザーの数などの他の要因によって異なります。 詳細については、Azure DevOps の価格
この 料金計算ツール は、20 人のユーザーで Azure DevOps を実行するための見積もりを提供します。
Azure DevOps は、ユーザーごとに月単位で課金されます。 必要な同時実行パイプラインに応じて、テスト ユーザーやユーザー基本ライセンスに加えて、より多くの料金が発生する可能性があります。
セキュリティ
Microsoft ホスト型エージェントとセルフホステッド エージェントのどちらを使用するかを選択する場合は、Microsoft ホスト型エージェントを使用する場合のセキュリティ上の利点を考慮してください。
環境に対するすべての変更がパイプラインを通じて行われることを確認します。 最小限の特権の原則にロールベースのアクセス制御 (RBAC) を実装し、ユーザーが環境にアクセスできないようにします。
依存関係を追跡し、ライセンスを管理し、脆弱性をスキャンし、依存関係を最新の状態に保つために、Azure Pipelinesの手順を統合することを検討してください。