Google Cloud Architecture Framework のこのドキュメントでは、ビルド、テスト、デプロイを自動化するためのベスト プラクティスについて説明します。
自動化を行うと、コードの更新などの繰り返しのプロセスに人間が関与することによるエラーを排除することで、ビルド、テスト、デプロイの標準化が進みます。このセクションでは、自動化する際にさまざまな検査と安全確保の仕組みを使用する方法について説明します。標準化されたマシン制御のプロセスにより、デプロイが安全に適用されるようになります。また、ユーザー エクスペリエンスに大きな影響を与えることなく、必要に応じて以前のデプロイを復元する仕組みも提供されます。
コードを中央のコード リポジトリに保存する
コードは、タグ付けされたバージョン管理システムと、コード変更のロールバック機能がある中央のコード リポジトリに保存します。バージョン管理を使用すると、ファイルを整理して、チームや組織全体にわたってアクセス、更新、削除を管理できます。
さまざまな開発段階では、必要に応じてリポジトリのバージョニングやラベル付けを行います。たとえば、ラベルは、test
、dev
、prod
などになります。
Google Cloud では、コードを Cloud Source Repositories に保存して、バージョニングや他の Google Cloud プロダクトと統合することが可能です。コンテナ化されたアプリケーションを構築する場合は、コンテナ用のマネージド レジストリである Artifact Registry を使用します。
バージョン管理の詳細については、DevOps 技術: バージョン管理をご覧ください。リポジトリを使用してトランクベース開発を実装する方法の詳細については、DevOps 技術: トランクベース開発をご覧ください。
継続的インテグレーションと継続的デプロイ(CI / CD)を使用する
デプロイは、継続的インテグレーションと継続的デプロイ(CI / CD)を使用して自動化します。CI / CD の手法は、開発チームが従っている構成や処理のパイプラインを組み合わることです。
CI / CD 手法では、ソフトウェア開発チームの生産性を改善することで、デプロイのスピードを上げます。この手法により、デベロッパーは、入念にテストされた小規模な変更をより頻繁に行うことができる一方で、変更のデプロイにかかる時間を削減できます。
CI / CD 手法の一環として、コードのビルド、テスト、デプロイのすべてのステップを自動化します。次に例を示します。
- 新しいコードがリポジトリに commit されるたびに、その commit によって自動的にビルドとテストのパイプラインが呼び出されます。
- 統合テストを自動化します。
- ビルドが特定のテスト基準を満たした後に変更がデプロイされるように、デプロイを自動化します。
Google Cloud では、CI / CD パイプラインに Cloud Build と Cloud Deploy を使用できます。
Cloud Build を使用すると、アプリケーション パッケージのパッケージ化とビルドに使用できる依存関係とバージョンを定義できます。ビルド構成をバージョニングしてすべてのビルドに一貫性を持たせ、必要に応じて以前の構成にロールバックできるようにします。
Cloud Deploy を使用すると、アプリケーションを Google Cloud の特定の環境にデプロイして、デプロイメント パイプラインを管理できます。
CI / CD の実装の詳細については、DevOps 技術: 継続的インテグレーションと DevOps 技術: デプロイの自動化をご覧ください。
Infrastructure as Code でインフラストラクチャをプロビジョニングして管理する
Infrastructure as Code とは、VM などのインフラストラクチャとファイアウォール ルールなどの構成を管理する記述モデルを使用することです。Infrastructure as Code を使用すると、次のことを行えます。
- CI / CD パイプラインのデプロイ環境やテスト環境など、クラウド リソースを自動的に作成する。
- インフラストラクチャの変更を、アプリケーションの変更と同じように扱う。たとえば、構成の変更がレビュー、テスト、監査されるようにします。
- クラウド インフラストラクチャに関する信頼できる唯一の情報源を確保する。
- 必要に応じて、クラウド環境を複製する。
- 必要に応じて以前の構成にロールバックする。
この Infrastructure as Code のコンセプトは、Google Cloud のプロジェクトにも適用されます。この方法を使用すると、プロジェクト内に共有 VPC 接続や Identity and Access Management(IAM)アクセスなどのリソースを定義できます。この方法の例については、Google Cloud Project Factory Terraform モジュールをご覧ください。
Terraform などのサードパーティ ツールを使用すると、Google Cloud にインフラストラクチャを自動的に作成できます。詳細については、Terraform、Cloud Build、GitOps を使用してインフラストラクチャをコードとして管理するをご覧ください。
重要なリソースを誤って削除することや、不正に削除されることから保護するために、プロジェクト リーエン、Cloud Storage の保持ポリシー、Cloud Storage バケットのロックなどの Google Cloud の機能の使用を検討してください。
ソフトウェア デリバリーのライフサイクル全体にテストを組み込む
ソフトウェアのリリースを成功させるには、テストが不可欠です。継続的なテストにより、チームが高品質のソフトウェアを迅速に作成でき、ソフトウェアの安定性が強化されます。
テストの種類は次のとおりです。
- 単体テスト。単体テストは高速で、迅速なデプロイに役立ちます。単体テストはコードベースの一部として扱い、ビルドプロセスの一部として追加します。
- 統合テスト。統合テストは、特にスケールするように設計され、複数のサービスに依存するワークロードにとって重要です。相互接続されたサービスとの統合をテストする際は、そのテストが複雑になることがあります。
- システムテスト。システムテストは時間がかかり、複雑ですが、デプロイ前にエッジケースを特定して問題を修正するのに役立ちます。
- その他のテスト。静的テスト、負荷テスト、セキュリティ テスト、ポリシー検証テストなど、他にも実行すべきテストがあります。これらのテストは、アプリケーションを本番環境にデプロイする前に実行します。
テストを組み込むには、次のようにします。
- ソフトウェア デリバリー ライフサイクル全体にわたって、全種類のテストを継続的に実施する。
- これらのテストを自動化し、CI / CD パイプラインに含める。いずれかのテストが失敗した場合は、パイプラインを失敗させます。
- デプロイを継続的に更新し、新しいテストを追加して、デプロイの運用状態を改善する。
テスト環境の場合は、次のようにします。
- 使用するテスト環境ごとに個別の Google Cloud プロジェクトを使用する。アプリケーションごとに個別のプロジェクト環境を使用します。この分離により、本番環境のリソースと下位環境のリソースが明確に区別されます。また、ある環境内での変更が、誤って他の環境に影響を与えることがなくなります。
- テスト環境の作成を自動化する。この自動化を行う方法の 1 つは、Infrastructure as Code を使用することです。
- 合成本番環境を使用して変更内容をテストする。この環境では、エンドツーエンドのテストやパフォーマンス テストなど、アプリケーションのテストと、ワークロードに対するさまざまな種類のテストを行う、本番環境に似た環境を提供します。
継続的なテストの実装の詳細については、DevOps 技術: 継続的テストをご覧ください。
デプロイを段階的に開始する
エンドユーザーの中断を最小化、ローリング アップデート、ロールバック方法、A/B テスト方法などの重要なパラメータに基づいて、デプロイ方針を選択します。ワークロードごとにこれらの要件を評価し、ローリング アップデート、Blue/Green デプロイ、カナリア デプロイなどの実証済みの手法からデプロイ方針を選択します。
変更は、CI / CD プロセスによってのみ、本番環境に push されます。
不変のインフラストラクチャの使用を検討してください。不変のインフラストラクチャとは、変更も更新もされないインフラストラクチャのことです。新しいコードをデプロイする必要がある場合や環境内の他の構成を変更する場合は、環境全体(VM や Pod のコレクションなど)を新しい環境に置き換えます。Blue/Green デプロイは、不変のインフラストラクチャの一例です。
変更をデプロイする際には、カナリアテストを行ってシステムのエラーを確認することをおすすめします。強力なモニタリングとアラートのシステムがあれば、このタイプのモニタリングは簡単です。A/B テストやカナリアテストには、Google Cloud のマネージド インスタンス グループを使用できます。その後、必要に応じて低速ロールアウトや復元を行います。
デプロイを自動化し、デプロイ パイプラインを管理するには、Cloud Deploy の使用を検討してください。また、Google Cloud での自動デプロイとデプロイ パイプラインの作成には、Spinnaker や Tekton のようなさまざまなサードパーティ ツールも使用できます。
以前のリリースをシームレスに復元する
復元方法は、デプロイ方針の一部として定義します。デプロイメントやインフラストラクチャ構成は、以前のバージョンのソースコードにロールバックできるようにします。以前の安定したデプロイメントを復元することは、信頼性とセキュリティ両方のインシデント管理における重要なステップです。
また、デプロイ プロセスの開始前の状態に環境を復元できるようにもします。これには次のものが含まれます。
- アプリケーションのコード変更を元に戻す機能。
- 環境に加えた変更を元に戻す機能。
- 不変のインフラストラクチャを使用して、デプロイによって環境が変更されないようにする。こうすることによって、構成の変更を元に戻しやすくします。
CI / CD パイプラインをモニタリングする
自動化されたビルド、テスト、デプロイ プロセスをスムーズに実行するため、CI / CD パイプラインをモニタリングします。いずれかのパイプラインで障害が発生したことを示すアラートを設定します。パイプラインが失敗した場合に根本原因を分析できるように、パイプラインの各ステップでは適切なログ ステートメントを書き出す必要があります。
Google Cloud では、すべての CI / CD サービスが Google Cloud のオペレーション スイートに統合されています。次に例を示します。
- Cloud Source Repositories は、Pub/Sub サービスと統合されています。
- Cloud Build は、Pub/Sub と統合され、監査ログとビルドログも保存されます。ビルドログに含まれる特定のキーワードや他の多くの指標に関するアラートは、Cloud Monitoring サービスを使用して設定できます。
- Cloud Deploy は監査ログを保存します。
モニタリングとロギングの詳細については、モニタリング、アラート、ロギングを設定するをご覧ください。
アプリケーションを安全にデプロイする
アーキテクチャ フレームワークのセキュリティ、コンプライアンス、プライバシーのカテゴリにある「アプリケーションを安全にデプロイする」セクションを確認してください。
バージョン リリースのための管理ガイドラインの確立する
エンジニアによるミスを防ぎ、ソフトウェアの配信スピードを上げるには、新しいソフトウェア バージョンをリリースするための管理ガイドラインが明確に文書化されている必要があります。
リリース エンジニアは、ソフトウェアがどのように構築され、配信されているかを監督します。リリース エンジニアリング システムは、次の 4 つの手法に基づいています。
セルフサービス モード。 ソフトウェア エンジニアがよくある間違いを避けるためのガイドラインを確立します。これらのガイドラインは一般に、自動プロセスにコード化されています。
頻繁なリリース。 高速化はトラブルシューティングに役立ち、問題の修正を容易にします。頻繁なリリースは自動化された単体テストに依拠します。
ハーメティック ビルド。ビルドツールとの整合性を確保します。バージョンのビルドに使用するビルド コンパイラのバージョンを 1 か月前と比較します。
ポリシーの適用。すべての変更には、コードの審査が必要です。セキュリティを強化するための一連のガイドラインとポリシーを含めることが理想的です。ポリシーの適用により、コードのレビュー、トラブルシューティング、新しいリリースのテストが改善されます。
次のステップ
- モニタリング、アラート、ロギングを設定する(このシリーズの次のドキュメント)
- アプリケーションを安全にデプロイする(アーキテクチャ フレームワークのセキュリティ、コンプライアンス、プライバシーのカテゴリにあります)
- コンテナ構築のおすすめの方法を確認する
- DevOps の研究: 技術面の DevOps 機能を確認する
- アーキテクチャ フレームワークの他のカテゴリ(システム設計、セキュリティ、プライバシー、コンプライアンス、信頼性、コストの最適化、パフォーマンスの最適化)を確認する。