翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# CI/CD について
継続的インテグレーションと継続的デリバリー (CI/CD) は、ソフトウェアリリースライフサイクルを自動化するプロセスです。場合によっては、CI/CD の *D* は*デプロイ*を意味することもあります。*継続的デリバリー*と*継続的デプロイ*の違いは、本番環境に変更をリリースする際に発生します。継続的デリバリーでは、変更を本番環境に昇格させる前に、手動による承認が必要です。継続的なデプロイは、パイプライン全体を通じて中断のないフローを特徴としており、明示的な承認は必要ありません。この戦略では一般的な CI/CD の概念について説明するため、提供される推奨事項および情報は、継続的デリバリーと継続的デプロイメントの両方のアプローチに適用できます。
CI/CD は、コミットから本番環境に新しいコードを移行するために従来必要とされていた手動プロセスの多く、またはすべてを自動化します。CI/CD パイプラインは、ソース、ビルド、テスト、ステージング、および本番環境の各ステージを包含します。各ステージにおいて、CI/CD パイプラインは、コードをデプロイまたはテストするために必要なすべてのインフラストラクチャをプロビジョニングします。CI/CD パイプラインを使用すると、開発チームはコードに変更を加えるだけで、その変更が自動的にテストおよびデプロイにプッシュされるようになります。
完全な CI/CD である状態から、意図的であるか無意識であるかにかかわらず、逸脱する可能性のあるいくつかの方法について説明する前に、基本的な CI/CD プロセスを確認しましょう。次の図は、CI/CD のステージと、各ステージにおけるアクティビティを示しています。
![\[CI/CD プロセスの 5 つのステージと、それぞれのアクティビティおよび環境。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/strategy-cicd-litmus/images/cicd-stages.png)
## 継続的インテグレーションについて
継続的インテグレーションは、GitHub の Git リポジトリなどのコードリポジトリで行われます。単一のメインブランチをコードベースの信頼できるソースとして扱い、機能開発用に短期間のブランチを作成します。機能を上位環境にデプロイする準備ができたら、機能ブランチをメインブランチに統合します。機能ブランチは、上位環境に直接デプロイされることは決してありません。詳細については、このガイドの「[トランクベースのアプローチ](fully-cicd-process-differences.md#trunk-based-approach)」を参照してください。
*継続的インテグレーションプロセス*
1. 開発者はメインブランチから新しいブランチを作成します。
1. 開発者は変更を行い、ビルドとテストをローカルで行います。
1. 変更の準備が整ったら、開発者はメインブランチを送信先として[プルリクエスト](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) (GitHub ドキュメント) を作成します。
1. コードがレビューされます。
1. コードが承認されると、そのコードはメインブランチにマージされます。
## 継続的デリバリーについて
継続的デリバリーは、開発環境や本番環境などの分離された環境で行われます。各環境で発生するアクションは状況によって異なる場合があります。多くの場合、最初のステージの 1 つは、先に進む前にパイプライン自体を更新するために使用されます。デプロイの最終的な結果は、各環境が最新の変更で更新されることです。ビルドおよびテスト用の開発環境の数も状況によって異なりますが、少なくとも 2 つを使用することを推奨します。パイプラインでは、各環境はその重要度の順に更新され、最後に本番環境 (最も重要な環境) が更新されます。
*継続的デリバリープロセス*
パイプラインの継続的デリバリーの部分は、ソースリポジトリのメインブランチからコードをプルし、それをビルドステージに渡すことによって開始されます。リポジトリの Infrastructure as Code (IaC) ドキュメントでは、各ステージで実行されるタスクを概説しています。IaC ドキュメントの使用は必須ではありませんが、IaC サービスまたはツール ([AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) や [AWS Cloud Development Kit (AWS CDK)](https://docs.aws.amazon.com/cdk/latest/guide/home.html) など) の使用は強く推奨されます。最も一般的なステップには、次のものがあります。
1. ユニットのテスト
1. コードのビルド
1. リソースのプロビジョニング
1. 統合テスト
パイプラインのいずれのステージでも、何らかのエラーが発生するかテストが失敗した場合は、現在のステージは以前の状態にロールバックされ、パイプラインは終了されます。後続の変更は、コードリポジトリで開始し、完全な CI/CD プロセスを経由する必要があります。
# CI/CD パイプラインのテスト
デプロイパイプラインで一般的に言及される 2 つのタイプの自動テストは、*ユニットテスト*と*統合テスト*です。ただし、コードベースや開発環境に対して実行できるテストには多くのタイプがあります。「[AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/application-pipeline/)」では、次のタイプのテストを定義しています。
+ **ユニットテスト** – これらのテストは、アプリケーションコードをビルドおよび実行し、それが期待どおりに動作していることを検証します。これらのテストでは、コードベースで使用されているすべての外部依存関係をシミュレートします。ユニットテストツールの例としては、[JUnit](https://junit.org/)、[Jest](https://jestjs.io/)、[pytest](https://pytest.org/) などがあります。
+ **統合テスト** – これらのテストは、プロビジョニングされたテスト環境に対してテストを実行することにより、アプリケーションが技術的要件を満たしていることを検証します。統合テストツールの例としては、[Cucumber](https://cucumber.io/)、[vRest NG](https://vrest.io/)、[integ-tests](https://docs.aws.amazon.com/cdk/api/v2/docs/integ-tests-alpha-readme.html) (AWS CDK 用) などがあります。
+ **受け入れテスト** – これらのテストは、プロビジョニングされたテスト環境に対してテストを実行することにより、アプリケーションがユーザー要件を満たしていることを検証します。受け入れテストツールの例としては、[Cypress](https://cypress.io/) や [Selenium](https://selenium.dev/) などがあります。
+ **合成テスト** – これらのテストはバックグラウンドで継続的に実行され、トラフィックを生成し、システムが正常であることを検証します。合成テストツールの例としては、[Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) や [Dynatrace Synthetic Monitoring](https://www.dynatrace.com/monitoring/platform/synthetic-monitoring/) などがあります。
+ **パフォーマンステスト** – これらのテストは、本番環境のキャパシティーをシミュレートします。アプリケーションがパフォーマンス要件を満たしているかどうかを判定し、メトリクスを過去のパフォーマンスと比較します。パフォーマンステストツールの例としては、[Apache JMeter](https://jmeter.apache.org/)、[Locust](https://locust.io/)、[Gatling](https://gatling.io/) などがあります。
+ **耐障害性テスト** – *カオステスト*とも呼ばれるこれらのテストは、リスク領域を特定するために環境に障害を注入します。その後、障害が注入された期間と障害のない期間を比較します。耐障害性テストツールの例としては、[AWS Fault Injection Service](https://aws.amazon.com/fis/)や [Gremlin](https://www.gremlin.com/) などがあります。
+ **静的アプリケーションセキュリティテスト (SAST)** – これらのテストは、[SQL インジェクション](https://owasp.org/www-community/attacks/SQL_Injection)や[クロスサイトスクリプティング (XSS)](https://owasp.org/www-community/attacks/xss/) などのセキュリティ違反がないか、コードを分析します。SAST ツールの例としては、[Amazon CodeGuru](https://aws.amazon.com/codeguru/)、[SonarQube](https://www.sonarqube.org/)、[Checkmarx](https://checkmarx.com/) などがあります。
+ **動的アプリケーションセキュリティテスト (DAST)** – これらのテストは、*ペネトレーションテスト* (または*ペンテスト*) とも呼ばれます。プロビジョニングされたテスト環境において、SQL インジェクションや XSS などの脆弱性を特定します。DAST ツールの例としては、[Zed Attack Proxy (ZAP)](https://www.zaproxy.org/) や [HCL AppScan](https://www.hcltechsw.com/appscan) などがあります。詳細については、「[ペネトレーションテスト](https://aws.amazon.com/security/penetration-testing/)」を参照してください。
すべての完全な CI/CD パイプラインがこれらすべてのテストを実行するわけではありません。ただし、少なくとも、パイプラインはコードベースに対してユニットテストおよび SAST テストを実行し、テスト環境に対して統合テストおよび受け入れテストを実行する必要があります。
# CI/CD パイプラインのメトリクス
「[AWS Deployment Pipeline Reference Architecture](https://pipelines.devops.aws.dev/application-pipeline/)」によると、CI/CD パイプラインについて、少なくとも次の 4 つのメトリクスを追跡する必要があります。
+ **リードタイム** – 単一のコミットが本番環境へ到達するまでにかかる平均時間。リードタイムは、ユースケースに応じて 1 時間から 1 日の範囲を目標に設定することを推奨します。
+ **デプロイ頻度** – 特定の期間内に本番デプロイを行う回数。デプロイ頻度は、ユースケースに応じて 1 日に複数回から週に 2 回の範囲を目標に設定することを推奨します。
+ **平均故障間隔 (MTBF)** — 成功したパイプラインの開始から、失敗したパイプラインの開始までの平均時間。MTBF は、できるだけ高い値を目標に設定することを推奨します。詳細については、「[MTBF の増加](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/increasing-mtbf.html)」を参照してください。
+ **平均復旧時間 (MTTR)** — 失敗したパイプラインの開始から、次の成功したパイプラインの開始までの平均時間。MTTR は、できるだけ低い値を目標に設定することを推奨します。詳細については、「[MTTR の削減](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/reducing-mttr.html)」を参照してください。
これらのメトリクスは、チームが完全な CI/CD の実現に向けた進行状況を追跡するのに役立ちます。チームは、最適な目標を何に設定すべきかについて、組織のステークホルダーとオープンな議論を行う必要があります。状況やニーズは、組織ごとに、場合によってはチームごとに大きく異なります。
急速で劇的な変化は、通常、問題が発生するリスクを高めることを忘れないようにすることが非常に重要です。小規模で段階的な改善を目指した目標を設定してください。完全な CI/CD パイプラインにおける最適なリードタイムは、一般的には 3 時間未満です。リードタイムが 5.2 日から始まるチームは、数週間ごとに 1 日短縮することを目標としてください。リードタイムが 1 日以下に達したら、チームはその状態を数か月間維持することができ、チームや組織のステークホルダーが必要と判断した場合にのみ、より短いリードタイムに移行できます。