OPS05-BP02 変更をテストし、検証する
デプロイされた変更はすべてテストし、本稼働でのエラーを回避する必要があります。このベストプラクティスは、バージョンコントロールからアーティファクトビルドへの変更をテストすることに重点を置いています。テストには、アプリケーションコードの変更に加えて、インフラストラクチャ、設定、セキュリティコントロール、運用手順も含める必要があります。テストは、単体テストからソフトウェアコンポーネント分析 (SCA) まで、さまざまな形態があります。ソフトウェアの統合および配信プロセスでテストをさらに早めると、アーティファクト品質の確実性が増します。
組織はすべてのソフトウェアアーティファクトにおいてテスト基準を作成する必要があります。テストを自動化すると、手間を軽減し、手動テストによるエラーを回避できます。手動テストが必要な場合もあります。開発者は自動テストの結果を確認して、ソフトウェアの品質を向上させるフィードバックループを作成する必要があります。
期待される成果:
-
ソフトウェアの変更は、配信前にすべてテストされる。
-
開発者はテスト結果を利用できる。
-
組織に、すべてのソフトウェア変更に適用されるテスト基準がある。
一般的なアンチパターン:
-
ソフトウェアの新しい変更を、テストせずにデプロイする。本稼働で実行に失敗し、その結果サービスが停止する。
-
新しいセキュリティグループが、本番前環境でのテストをせずに AWS CloudFormation にデプロイされる。そのセキュリティグループによって、ユーザーがアプリにアクセスできなくなる。
-
メソッドが変更されたが単体テストがなかった。本稼働にデプロイされた際にソフトウェアが失敗した。
このベストプラクティスを活用するメリット:
-
ソフトウェアのデプロイにおける変更失敗率が軽減されます。
-
ソフトウェアの品質が向上します。
-
開発者のコードの成立性に対する意識が上がります。
-
セキュリティポリシーを確信を持ってロールアウトし、組織のコンプライアンスをサポートできます。
-
自動スケーリングポリシーの更新などインフラストラクチャの変更を事前にテストし、トラフィックのニーズを満たすことができます。
このベストプラクティスが確立されていない場合のリスクレベル: 高
実装のガイダンス
継続的統合の実践の一部として、アプリケーションコードからインフラストラクチャまで、すべての変更に対してテストを行います。テスト結果は、開発者が迅速にフィードバックを得られるように公開します。組織に、すべてのソフトウェア変更に適用されるテスト基準を備えます。
お客様事例
AnyCompany Retail は、継続的な統合パイプラインの一部として、すべてのソフトウェアアーティファクトに対して複数種類のテストを実行しています。テスト駆動開発を実践しているため、すべてのソフトウェアに単体テストがあります。アーティファクトがビルドされると、エンドツーエンドのテストが実行されます。1 ラウンド目のテストが完了すると、静的アプリケーションセキュリティスキャンを実行し、既知の脆弱性を探します。開発者は、各テストに合格するたびにメッセージを受け取ります。すべてのテストが完了すると、ソフトウェアアーティファクトはアーティファクトリポジトリに保存されます。
実装手順
-
組織の関係者と協力して、ソフトウェアアーティファクトのテスト基準を作成します。すべてのアーティファクトが合格しなければならない基準のテストとは何でしょうか? テスト範囲に含める必要があるコンプライアンスやガバナンスの要件はありますか? コード品質テストを実施する必要がありますか? テストが完了した際に通知が必要なのは誰ですか?
-
AWS デプロイパイプラインリファレンスアーキテクチャ
には、統合パイプラインの一部としてソフトウェアアーティファクトに対して実行できる、テストの種類の信頼できるリストが含まれています。
-
-
ソフトウェアテスト基準に基づいて必要なテストを行い、アプリケーションを計測します。テストの各セットは 10 分以内に完了する必要があります。テストは統合パイプラインの一部として実行する必要があります。
-
Amazon CodeGuru Reviewer では、アプリケーションコードをテストして欠陥を検出できます。
-
AWS CodeBuild を使用して、ソフトウェアアーティファクトに対しテストを実施できます。
-
AWS CodePipeline は、ソフトウェアテストをパイプラインに組み込むことができます。
-
リソース
関連するベストプラクティス:
-
OPS05-BP01 バージョン管理を使用する - すべてのソフトウェアアーティファクトはバージョン管理されたリポジトリにバックアップされる必要があります。
-
OPS05-BP06 設計標準を共有する - 組織のソフトウェアテスト基準によって、設計基準がわかります。
-
OPS05-BP10 統合とデプロイを完全自動化する - ソフトウェアテストは、より大きな統合およびデプロイパイプラインの一部として、自動で実行する必要があります。
関連するドキュメント:
-
Adopt a test-driven development approach (テスト駆動の開発アプローチを導入する)
-
Automated AWS CloudFormation Testing Pipeline with TaskCat and CodePipeline
(TaskCat と CodePipeline を使用した自動 CloudFormation テストパイプライン) -
Building end-to-end AWS DevSecOps CI/CD pipeline with open source SCA, SAST, and DAST tools
(オープンソースの SCA、SAST、DAST ツールを使用してエンドツーエンドの AWS DevSecOps CI/CD パイプラインを構築する) -
Getting started with testing serverless applications
(サーバーレスアプリケーションのテストを開始する) -
My CI/CD pipeline is my release captain
(CI/CD パイプラインが自分のリリースキャプテン)
関連動画:
-
AWS re:Invent 2020: Testable infrastructure: Integration testing on AWS
(re:Invent 2020: テスト可能なインフラストラクチャ: AWS での統合テスト) -
AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development
(Summit ANZ 2021 - CDK とテスト駆動開発でテストファースト戦略を獲得する) -
Testing Your Infrastructure as Code with AWS CDK
(AWS CDK で Infrastructure as Code をテストする)
関連リソース:
-
Policy as Code Workshop – Test Driven Development
(Policy as Code ワークショップ - テスト駆動開発) -
Run unit tests for a Node.js application from GitHub by using AWS CodeBuild(AWS CodeBuild を使用して GitHub から Node.js アプリケーションの単体テストを実行する)
-
Use Serverspec for test-driven development of infrastructure code (インフラストラクチャコードのデータ駆動開発に Serverspec を使用する)
関連サービス: