

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# 継続的インテグレーションと継続的デリバリー
<a name="ci-cd"></a>

**従来のソフトウェア開発およびインフラストラクチャ管理プロセスを使用している組織よりも、迅速にアプリケーションとサービスを進歩させ改善します。**

[DevOps](https://aws.amazon.com/devops/) プラクティスを[継続的インテグレーション](https://aws.amazon.com/devops/continuous-integration/)および[継続的デリバリー](https://aws.amazon.com/devops/continuous-delivery/) (CI/CD) とともに導入すると、アプリケーションの構築、テスト、デプロイのプロセスを合理化、自動化、効率化できます。CI/CD により、ソフトウェアデリバリーの迅速化や、デプロイエラーリスクの軽減を行えるほか、最新の機能やバグ修正を加えることで、アプリケーションを常に最新状態に維持できます。主な目的は、従来のソフトウェア開発およびインフラストラクチャ管理プロセスの手順を発展させ、アプリケーションとサービスの高度化と改善を短期間で行えるようにすることです。

## Start
<a name="ci-cd-start"></a>

### ソフトウェアコンポーネント管理を導入する
<a name="ci-cd-components"></a>

ソフトウェアコンポーネント管理とは、コンポーネント管理のプラクティスであり、このプラクティスでは、ライブラリ、フレームワーク、ソースコードリポジトリ、モジュール、アーティファクト、サードパーティー製要素との依存関係といった、ソフトウェア構築に使用する個々のコンポーネントをすべて管理します。これを実践する場合は、Git や Apache Subversion などのバージョン管理システムを使用して、ソースコードの管理、コラボレーション環境の実現、コード変更履歴の維持などを行うと良いでしょう。リポジトリ内での変更およびイベントをモニタリングすると、プロセス自動化、パイプライン作成、コード管理を行え、必要であれば、ワークフローを追加のサービスと統合できます。 

### CI/CD パイプラインを作成する
<a name="ci-cd-pipelines"></a>

CI/CD パイプラインとは、自動化された一連の手順であり、バージョン管理システムに変更をコミットすることで、これらを開始します。パイプラインは、通常、アプリケーションの構築、自動テストの実行、特定の環境にコードをデプロイする手順などで構成されます。自動 CI/CD パイプラインは、[AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)、Jenkins、GitLab、CircleCI などのツールを使用してセットアップできます。また、パイプライン生成をサポートするバージョン管理システム内に、直接セットアップすることも可能です。

最初に、継続的インテグレーションを目的とした最小限の実行可能なパイプラインを作成し、さらに多くのアクションとステージからなる[継続的デリバリー](https://aws.amazon.com/builders-library/going-faster-with-continuous-delivery/?did=ba_card&trk=ba_card)パイプラインに移行します。継続的デリバリーの設定は、コードとして扱います。ブランチやチームごとに個別のパイプラインを複数使用できるため、セットアップが必要な設定変数や、パイプラインを使用するチームに最適なサポート方法を検討してください。

次に、デプロイウィンドウ (コードをデプロイする日時) を検討します。システム需要が低い時間帯を対象として考えると、ロールバックの必要がある場合に、顧客への影響を最小化できるでしょう。その他のベストプラクティスには、金曜日のデプロイを避けるや、ピーク時または休日前にコードフリーズを行うなどがあります。作成者がコミットできない場合 (休暇中など) のコードデプロイのルールを定義することも検討してください。デプロイが失敗し、外部のサポートに頼らざるを得ない場合もあることに注意します。また、インプレース、ローリング、イミュータブル、ブルー/グリーンデプロイといったさまざまな[デプロイ方法](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)を評価するとともに、継続的デリバリーワークフローにフルマネージドサービスを利用することも検討します。このサービスにより、可用性とセキュリティを強化し、複雑さと管理労力を最小限に抑えられます。

### 自動テストをデプロイする
<a name="ci-cd-testing"></a>

最新のプラクティスとして、*シフトレフト* (開発者が認識しやすく [IDE](https://aws.amazon.com/what-is/ide/) が使用されているタイミングや、開発ライフサイクルの早い段階でテストを行うこと) をお勧めします。これにより、問題をリポジトリにコミットしてパイプラインを開始する前に、問題を検出し修正することができます。この方法を取ると、開発者のコーディング中にエラーが検出されるため、開発者との間で、すぐにフィードバックとそれへの対応を繰り返すことができます。シフトレフトのテストでは、パイプラインの実行が必要でないため、コスト削減につながりますが、それが必要な場合は、フィードバックが途切れがちになり、運用コストも増加する可能性があるでしょう。

自動テストは、開発プロセスの早い段階でエラーを検出するものですが、ここでは、ユニットテスト、統合テスト、機能テストも行います。そのため、[開発者には、できるだけ早く、ツールを使用](https://aws.amazon.com/products/developer-tools/)して単体テストを作成するよう勧め、中央リポジトリにコードをプッシュする前に、それらを実行してもらうと良いでしょう。さらに、自動化プロセスに、[静的コード分析](https://aws.amazon.com/blogs/devops/automating-detection-of-security-vulnerabilities-and-bugs-in-ci-cd-pipelines-using-amazon-codeguru-reviewer-cli/)、パフォーマンスベンチマーク、セキュリティアプリケーションテストが含まれていることも確認します。

### ドキュメントを作成する
<a name="ci-cd-docs"></a>

CI/CD パイプラインを実装して開発ワークフローを合理化するだけでなく、明確で包括的なドキュメントも維持し、パイプラインでの有効性、保守性、スケーラビリティを継続的に確保する必要があります。開発チームがパイプラインの設計、コンポーネント、プロセスを明確に理解するできるようにするという点で、CI/CD パイプラインでは、ドキュメントが重要な役割を果たします。ドキュメントの作成時には、最初にパイプラインを概説します。続いて、アーキテクチャおよび設計のトレードオフ、使用するツールと技術、具体的な初期設定および各種設定、セキュリティ対策とアクセスコントロールなどを説明し、トラブルシューティングとメンテナンスの情報も追加します。

### Infrastructure as Code を使用する
<a name="ci-cd-iac"></a>

Terraform、Ansible、[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html) のツールでインフラストラクチャを管理し、一貫性と再現性のある環境を実現します。インフラストラクチャをコードとして扱い、インフラストラクチャの変更を追跡し、変更はコンソールから直接行わないようにします。すべてのインフラストラクチャをコードとして定義し、パイプラインを使用してこれらの変更をデプロイします。データベースもコードとして定義し、プロビジョニングします。サニタイズ済み本番データの小規模サブセットを使用して、パイプラインでデータベース統合をコードとして実行することを検討してください。可能であれば、コードを変更し、そうした変更を追跡します。

ソフトウェアのコードと同様、インフラストラクチャのコードでも、次のベストプラクティスに従います。
+ バージョンコントロールを使用します。
+ バグ追跡およびチケット発行システムを使用します。
+ 適用前に、変更を同僚に確認してもらいます。
+ インフラストラクチャコードのパターンおよび設計を確立します。
+ インフラストラクチャの変更をテストします。

### 標準メトリクスを維持および追跡します。
<a name="ci-cd-metrics"></a>

高レベルのパフォーマンスを維持するには、主要なメトリクスを開発して追跡し、以下の点から、パイプラインの正常性とビジネスへの影響を把握します。
+ **ビルド頻度。**ビルド数からは、チームの生産性と変更の複雑さに関するインサイトを得られます。
+ **デプロイ頻度。**定期的なデプロイは、健全でアジャイルな開発プロセスを示しています。
+ **変更のリードタイム。**変更が本番環境に反映される平均時間を測定すると、デプロイプロセスのボトルネックの特定に役立ちます。
+ **パイプラインの平均所要時間。**最初のパイプラインステージから後続の各ステージまでにかかる平均時間の情報は、ワークフローの最適化に役立ちます。
+ **本番環境の変更回数。**本番環境に反映させる変更の数を追跡すると、本番環境の安定性についてインサイトを得られます。
+ **ビルド時間** 平均ビルド時間は、コードベースまたはインフラストラクチャで起こり得る問題を示している可能性があります。

## 高度化
<a name="ci-cd-advance"></a>

### 設定管理ツールを使用する
<a name="ci-cd-config"></a>

設定管理ツールは、ソフトウェアおよびインフラストラクチャのデプロイ、設定、管理を自動化する上で重要な役割を果たします。こうしたツールの体系的なアプローチによって、変更を処理するとともに、さまざまな環境のインフラストラクチャ、ソフトウェア、設定を望ましい状態に維持できます。また、開発者が宣言言語または命令言語を使用して、システムの望ましい状態を定義できるようになり、それらの設定をターゲットシステムに適用するプロセスを自動化することで、一貫性と再現性も確保されます。

設定管理ツールを使用して、ソフトウェアおよびインフラストラクチャのデプロイ、設定、管理を自動化します。[AWS Systems ManagerState Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state.html) は、安全でスケーラブルな設定管理サービスで、これにより、マネージドノードや他の AWS リソースを、定義した状態に維持するプロセスを自動化できます。

### モニタリングとログ記録を統合する
<a name="ci-cd-monitoring"></a>

モニタリングおよびログ記録のソリューションを CD パイプラインに統合すると、開発チームとソフトウェア開発プロセス全体で多くの利点を得られます。これらのソリューションにより、アプリケーションパフォーマンスに関するリアルタイムのインサイト取得、問題の迅速な特定と解決、継続的改善の促進などが可能になるため、アプリケーションライフサイクル全体を通して、信頼性、パフォーマンス、スケーラビリティを維持しやすくなります。モニタリングおよびログ記録ソリューションへの投資は、堅牢で効率的な CD パイプラインを維持する上で重要な側面であり、高品質のソフトウェアを提供するという成果につながります。

### マージのケイデンスを決定する
<a name="ci-cd-cadence"></a>

コード変更は、メインライン (トランクまたはメイン) ブランチに少なくとも 1 日に 1 回、理想的には各タスクの後 1 日に複数回コミットまたはマージします。こうしたケイデンスにより、毎日複数のパイプライン呼び出しが発生します。プルベースの分岐ワークフローモデルは、そのようなアプローチに沿ったものです。[機能フラグ](https://aws.amazon.com/blogs/mt/using-aws-appconfig-feature-flags/)、[ダークローンチ](https://martinfowler.com/bliki/DarkLaunching.html)や同様の手法を使用すると、顧客が使用する機能をカスタマイズできます。 

### デプロイ後の動作をキャプチャする
<a name="ci-cd-post-deploy"></a>

デプロイ後、自動合成テストを使用して本番環境の動作をキャプチャし、結果を継続的デリバリーパイプラインと同期することで、是正措置を迅速に行えるようにします。開発者にとっての最優先事項は、パイプラインで検出されたエラーをできるだけ早く修正して、コード変更をソースコードリポジトリにコミットし、パイプラインでエラー解決を検証することです。

デプロイ後のベストプラクティスとして、最も重要な主要業績評価指標 (KPI) を観察するとともに、本番環境にエラーがないことを検証すると良いでしょう。また、エラー処理の自動化と、デプロイ後の KPI 評価によって、リリースの影響を定量化することと、開発者が改善に利用できる速度、セキュリティ、安定性のメトリクスを自動的に生成することも推奨されます。詳細については、AWS の「[DevOps Monitoring Dashboard](https://aws.amazon.com/solutions/implementations/aws-devops-monitoring-dashboard/)」を参照してください。

## Excel
<a name="ci-cd-excel"></a>

最先端のプラクティスと技術を導入して、最適なパフォーマンスを実現します。CI/CD プロセスを継続的に改善することで、ソフトウェアの品質改善、市場投入の迅速化、俊敏性の向上が可能になります。新しい手法やツールは継続的に出現するため、最新情報を常に把握してそれらに適応し、競争上の優位性を維持することがきわめて重要です。

適応性を維持するには、次の点を考慮します。
+ アプリケーション、設定、インフラストラクチャ、データ、AWS アカウントと組織、デプロイパイプライン、ネットワーク、セキュリティおよびコンプライアンス管理といったあらゆる要素をコードとして定義します。
+ コンピューティングイメージ、共有サービス、アプリケーションそれぞれに応じた[デプロイパイプライン](https://aws-samples.github.io/aws-deployment-pipeline-reference-architecture)を作成します。
+ GitOps モデルの導入を検討します。このモデルに従ってプルベースのリクエストでワークフローを開始することで、コードの記述どおりに、既存インフラストラクチャの状態と望ましい状態を比較しながら変更をデプロイします。
+ CD パイプラインを使用して、機械学習 (ML)、データ、モノのインターネット (IoT) といったワークロードをデプロイすることを検討します。
+ すべてのビルドアーティファクトにデジタル署名し、安全なリポジトリに保存します。
+ ソフトウェアの出どころを追跡します。これを行うには、ソフトウェア部品表を自動生成することで、顧客にデプロイするすべてのアーティファクト (バージョン管理とデジタル署名の対象) を記録します。
+ ソフトウェアデリバリープロセス内の手動アクティビティをすべて削除した後に、手動のレビューボードを削除します。

ソフトウェアデリバリープロセス全体が自動化されたアプリケーションおよびサービスの場合は、継続的デプロイを検討してください。この手法では、パイプライン内の全チェックに合格した変更を顧客の本番環境にデプロイします。可視化については、AWS ウェブサイトで、「[What is Continuous Delivery?](https://aws.amazon.com/devops/continuous-delivery/)」にある最初の図を参照してください。

### AI/ML 技術を統合する
<a name="ci-cd-aiml"></a>

人工知能 (AI) と機械学習 (ML) の技術を CI/CD パイプラインに統合すると、次のような利点を得られます。
+ 自動テスト生成
+ テストの優先順位付けのインテリジェント化
+ 予測分析による問題検出
+ 異常検出と根本原因分析
+ コードレビューと品質保証
+ デプロイの最適化

詳細については、AWS ウェブサイトの「[デベロッパーのオペレーションにインテリジェンスを追加する](https://aws.amazon.com/machine-learning/ml-use-cases/ai-for-devops/)」を参照してください。

### カオスエンジニアリングプラクティスを導入する
<a name="ci-cd-chaos"></a>

カオスエンジニアリングでは、意図的にシステム障害を発生させ、システムが持つ予期しないイベントへの耐性と、回復力をテストします。これにより、弱点を特定し、プロアクティブに対処できるため、システム全体の信頼性が向上し、起こり得る問題の影響が最小化されます。

カオスエンジニアリングプラクティスを導入してシステムの耐障害性をテストするには、Gremlin、Chaos Monkey、Litmus などのツールを使用します。また、制御された実験を定期的に実行して脆弱性を特定し、耐障害性を検証するとともに、予期しない障害が適切に処理されるようアプリケーションを強化します。こうしたプロアクティブなアプローチが、システムの信頼性向上や、より堅牢な CI/CD パイプラインの実現に寄与するのです。

### パフォーマンスの最適化
<a name="ci-cd-perf"></a>

アプリケーションのパフォーマンスを継続的に最適化するには、プロファイリングツール、リアルタイムモニタリング、フィードバックループを使用します。例えば、次のような手法を適用して、増加したトラフィックと需要をアプリケーションで処理できるようにします。
+ コード最適化
+ プロファイリング
+ リアルタイムモニタリング
+ フィードバックループ
+ キャッシュ
+ 負荷分散
+ スケーラビリティおよびパフォーマンスのテスト

### 高度なオブザーバビリティを実装する
<a name="ci-cd-adv-observability"></a>

クラウドインフラストラクチャのオブザーバビリティを高めるには、メトリクス、ログ、トレースの基本的な収集、集約、分析を超える機能が必要です。[Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html) や [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) などのツールによってオブザーバビリティを強化すると、継続的デリバリーおよびイノベーションを推進する戦略的プラクティスに発展させることができます。

堅牢な CI/CD パイプラインで高度なオブザーバビリティを実現すると、アプリケーションやインフラストラクチャだけでなく、パイプライン自体を含め、システム全体のパフォーマンスと正常性に関するインサイトを導き出せます。こうしたインサイトにより、以下の対応を行えます。
+ 起こり得る問題を迅速に特定、理解、対処して、アプリケーションの安定性を向上させるとともに、ダウンタイムを削減する
+ CI/CD プロセスを合理化して、より迅速で信頼性の高いデリバリーを行う
+ コード変更とデプロイの影響を詳細に把握し、情報に基づく意思決定を促進する
+ リソース使用の最適化によって、業務効率と費用対効果を向上させる

オブザーバビリティを高めるには:
+ オブザーバビリティをアプリケーションとインフラストラクチャの全レイヤーで確保し、包括的なビューで、システムのパフォーマンス、動作、正常性を確認できるようにします。
+ Amazon CloudWatch などのツールによって、データ収集、ストレージ、分析を一元化することで、オブザーバビリティデータを統合し、アクセスや解釈を容易に行えるようにします。
+ 分散トレースに AWS X-Ray を使用して、アプリケーションとその基盤サービスのパフォーマンスを把握します。
+ 継続的改善のフィードバックループを確立するとともに、オブザーバビリティデータを使用してシステムの反復的な機能強化を推進します。

高度なオブザーバビリティの導入で重要なのは、システムの維持だけではありません。運用上の優秀性実現と継続的イノベーション推進に向けた戦略的な活動も重視する必要があります。

### GitOps プラクティスを実装する
<a name="ci-cd-adv-gitops"></a>

GitOps プラクティスを実装し、Git リポジトリを信頼できる単一のソースとして使用して、インフラストラクチャとアプリケーションの設定を管理します。こうしたアプローチを取ることで、変更管理の簡素化、トレーサビリティの向上、環境間での一貫性確保などが可能になります。