継続的インテグレーションと継続的デリバリーにおけるテストステージ

3 つの CI/CD チームは、CI/CD パイプラインの様々なステージでソフトウェア開発ライフサイクルにテストを組み込む必要があります。全体として、テストはできるだけ早期に開始する必要があります。以下に示すテストのピラミッドは、Succeeding with Agile で Mike Cohn により提示されている概念です。これは、テストのコストとスピードとの関係において、さまざまなソフトウェアテストを示しています。

CI/CD テストのピラミッド

ユニットテストは、ピラミッドの底にあります。これらは、実行が最も高速で、最も低コストです。したがって、ユニットテストはテスト戦略の大半を占める必要があります。目安としては、約 70% です。このフェーズで発見されたバグは迅速かつ安価に修正できるため、ユニットテストにはほぼ完全なコードカバレッジが必要です。

サービス、コンポーネント、および統合テストは、ピラミッドでユニットテストの上に位置します。これらのテストには詳細な環境が必要なため、インフラストラクチャ要件においてコストが高くなり、実行が遅くなります。次のレベルは、パフォーマンスとコンプライアンスのテストです。これらは、本稼働品質の環境を必要とし、さらにコストが高くなります。UI およびユーザー受け入れテストは、ピラミッドの最上部にあり、同様に本稼働品質の環境を必要とします。

これらのすべてのテストは、高品質なソフトウェアを保証するための完全な戦略の一部です。しかし、開発スピードのためには、ピラミッドの下半分のテストの数とカバレッジが重要視されます。

以下のセクションでは、CI/CD のステージについて説明します。

ソースのセットアップ

プロジェクトの開始時には、未処理のコードと設定、およびスキーマの変更を保存できるソースをセットアップすることが不可欠です。ソースステージでは、GitHub または AWS CodeCommit などでホストされているソースコードリポジトリを選択します。

ビルドの設定と実行

ビルドのオートメーションは、CI プロセスにとって不可欠です。ビルドのオートメーションを設定する際、最初のタスクは適切なビルドツールを選択することです。次のようなビルドツールが多数あります。

• Ant for Java、Maven for Java、Gradle for Java

• Make for C/C++

• Grunt for JavaScript

• Rake for Ruby

お客様にとって最適なビルドツールは、プロジェクトのプログラミング言語やチームのスキルセットによって異なります。ビルドツールを選択したら、すべての依存関係をビルドスクリプトおよびビルドステップに明確に定義する必要があります。また、最終的なビルドアーティファクトのバージョンを作成することもベストプラクティスです。これにより、デプロイおよび問題の追跡が容易になります。

構築

ビルドステージでは、ビルドツールはソースコードリポジトリへの変更を入力として受け取り、ソフトウェアをビルドし、次のタイプのテストを実行します。

ユニットテスト – コードの特定のセクションをテストして、期待されていることをコードが実行することを確認します。ユニットテストは、開発フェーズでソフトウェアデベロッパーが実行します。このステージでは、静的コード分析、データフロー分析、コードカバレッジ、およびその他のソフトウェア検証プロセスを適用することができます。

静的コード分析 – このテストは、ビルドおよびユニットテストの後にアプリケーションを実際に実行することなく実施されます。この分析は、コーディングエラーおよびセキュリティホールを見つけるのに役立ち、コーディングガイドラインへの準拠を確認することもできます。

ステージング

ステージングフェーズでは、最終的な本稼働環境を反映した完全な環境が作成されます。以下のテストが実行されます:

統合テスト – ソフトウェア設計に対してコンポーネント間のインターフェイスを検証します。統合テストは、反復的なプロセスであり、堅牢なインターフェイスおよびシステムの整合性の構築を容易にします。

コンポーネントテスト – さまざまなコンポーネント間のメッセージの受け渡しとその結果をテストします。このテストの主な目的は、コンポーネントテストにおける冪等性を確保することである場合があります。テストには、非常に大きなデータボリューム、または境界条件や異常な入力が含まれる可能性があります。

システムテスト – システムテストをエンドツーエンドでテストし、ソフトウェアがビジネス要件を満たしているかどうかを確認します。このテストには、ユーザーインターフェイス (UI)、API、バックエンドロジック、および終了状態のテストが含まれる場合があります。

パフォーマンステスト – 特定のワークロードで実行する際のシステムの応答性と安定性を判定します。パフォーマンステストは、スケーラビリティ、信頼性、リソース使用状況など、システムのその他の品質属性を調査、測定、または検証するためにも使用されます。パフォーマンステストのタイプには、ロードテスト、ストレステスト、スパイクテストなどが含まれます。パフォーマンステストは、事前定義された基準に対するベンチマークに使用されます。

コンプライアンステスト – コード変更が機能以外の仕様や規定の要件に準拠しているかどうかを確認します。これにより、定義済みの基準を実装し満たしているかどうかを判定します。

ユーザー受け入れテスト – エンドツーエンドのビジネスフローを検証します。このテストは、ステージング環境でエンドユーザーにより実行され、システムが要件仕様書の要件を満たしているかどうかを確認します。通常、お客様はこのステージにアルファテストおよびベータテストの方法論を採用しています。

本稼働

最後に、これまでのテストに合格した後に、本稼働環境でステージングフェーズが繰り返されます。このフェーズでは、コードを本稼働環境全体にデプロイする前に、新しいコードをサーバーの小さなサブセット、あるいは 1 つのサーバーや 1 つの AWS リージョン のみにデプロイすることで最終的な canary テストを完了することができます。本稼働環境に安全にデプロイする方法の詳細については、「デプロイ方法」のセクションで説明しています。

次のセクションでは、これらのステージとテストを組み込むためにパイプラインを構築する方法について説明します。