# 継続的インテグレーションと継続的デリバリーの実装
このセクションでは、お客様の組織で CI/CD モデルの実装を開始する方法について説明します。このホワイトペーパーでは、成熟した DevOps およびクラウド移行モデルを使用している組織が CI/CD パイプラインを構築して使用する方法については説明していません。DevOps の道のりを支援するために、AWS にはリソースとツールを提供できる数多くの[認定 DevOps パートナー](https://aws.amazon.com/devops/partner-solutions/)がいます。AWS クラウドへの移行の準備に関する詳細については、『[クラウド運用モデルの構築](https://d1.awsstatic.com/whitepapers/building-a-cloud-operating-model.pdf)』を参照してください。
# 継続的インテグレーションと継続的デリバリーへの道筋
CI/CD は、パイプラインとして描くことができます (下の図を参照)。ここでは、一方の端で新しいコードが引き渡され、一連のステージ (ソース、ビルド、ステージング、本稼働) でテストされた後、本稼働環境で使用できるコードとして公開されます。組織が初めて CI/CD を使用する場合、このパイプラインに反復的な方法でアプローチできます。つまり、小さく始めて各ステージで反復することです。これにより、組織の成長に役立つ方法でコードを理解し開発できるようになります。
![\[CI/CD パイプライン\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image2.png)
*CI/CD パイプライン*
CI/CD パイプラインの各ステージは、デリバリープロセスの論理ユニットとして構造化されています。さらに、各ステージは、コードの特定の側面を吟味するゲートとして機能します。コードがパイプラインを進むにつれて、より多くの側面が検証され続けるため、後のステージではコードの品質が高くなると想定されます。早いステージで問題が明らかになると、そのコードはパイプライン上の進行が停止します。テストの結果は即座にチームに送信され、ソフトウェアがステージをパスしなければ、それ以降のビルドやリリースはすべて停止されます。
これらのステージは提案です。ビジネスニーズに基づいてステージを適応させることができます。一部のステージは、複数のタイプのテスト、セキュリティ、およびパフォーマンスのために繰り返すことができます。プロジェクトの複雑さやチームの構造によって、一部のステージを異なるレベルで複数回繰り返すことができます。例えば、あるチームの最終成果物に、次のチームのプロジェクトが依存する場合があります。つまり、最初のチームの最終製品は、続いて次のチームのプロジェクトでアーティファクトとしてステージングされます。
CI/CD パイプラインの存在は、組織能力の成熟に大きな影響を与えます。組織は、開始時点から複数の環境、多くのテストフェーズ、およびすべてのステージでのオートメーションを備えた完全に成熟したパイプラインを構築しようとするのではなく、小さなステップから開始する必要があります。高度に成熟した CI/CD 環境を持つ組織であっても、パイプラインを継続的に改善する必要があることに留意してください。
CI/CD に対応した組織の構築は長い道のりであり、その道には多くの目的地があります。次のセクションでは、継続的インテグレーションから始まり継続的デリバリーのレベルに至るまで、組織が取り得る道筋について説明します。
# 継続的インテグレーション
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-source-and-build.png)
*継続的インテグレーション — ソースとビルド*
CI/CD の 道のりにおける最初のフェーズは、継続的インテグレーションでの成熟度を高めることです。すべてのデベロッパーが定期的にコードをセントラルリポジトリ (CodeCommit や GitHub にホストされているもの) にコミットし、すべての変更をアプリケーションのリリースブランチにマージしていることを確認する必要があります。デベロッパーは、単独でコードを保持するべきではありません。一定期間だけ機能ブランチが必要な場合、可能な限り頻繁に上流からマージして最新の状態に維持する必要があります。完全な作業単位での頻繁なコミットとマージは、チームが規律を確立するために推奨され、プロセスによって促進されます。コードを早期かつ頻繁にマージすれば、後に統合の問題が発生する可能性が少なくなります。
また、アプリケーションのテストユニットをできる限り早く作成し、コードをセントラルリポジトリにプッシュする前にこれらのテストを実行するようデベロッパーを促す必要があります。ソフトウェア開発プロセスの早い段階で発見されたエラーは、修正が最も低コストで容易です。
コードがソースコードリポジトリのブランチにプッシュされると、そのブランチを監視するワークフローエンジンがビルダーツールにコマンドを送信し、コードを構築し、制御された環境でユニットテストを実行します。ビルドプロセスは、迅速なフィードバックのために、コミットステージで発生する可能性があるプッシュやテストを含む、すべてのアクティビティを処理するために適切なサイズにする必要があります。ユニットテストカバレッジ、スタイルチェック、静的分析などのその他の品質チェックもこのステージで実行できます。最後に、ビルダーツールは、1 つまたは複数のバイナリビルドおよびアプリケーション用のイメージ、スタイルシート、ドキュメントなどの他のアーティファクトを作成します。
# 継続的デリバリー: ステージング環境の作成
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-staging.png)
*継続的デリバリー — ステージング*
継続的デリバリー (CD) は、次のフェーズであり、ステージング環境へのアプリケーションコードのデプロイを伴います。ステージング環境は、本稼働スタックのレプリカであり、より機能的なテストを実行します。ステージング環境は、テスト用に事前準備した静的環境を使用するか、アプリケーションコードのテストおよびデプロイ用にコミットされたインフラストラクチャと設定コードを使用して動的な環境をプロビジョンし設定することもできます。
# 継続的デリバリー : 本稼働環境の作成
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-production.png)
*継続的デリバリー — 本稼働*
デプロイ/デリバリーのパイプラインシーケンスでは、ステージング環境の後に本稼働環境があり、これも Infrastructure as Code (IaC) を使用して構築されます。
# 継続的デプロイ
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cd-cd.png)
*継続的デプロイ*
CI/CD デプロイパイプラインの最後のフェーズは、継続的デプロイです。これは、本稼働環境へのデプロイなどのソフトウェアリリースプロセス全体の完全なオートメーションを含む場合があります。完全に成熟した CI/CD 環境では、本稼働環境への道筋は完全に自動化され、コードを高い信頼性でデプロイすることが可能になります。
# 成熟とその先
組織が成熟すると、CI/CD モデルの発展が継続し、以下の改善点のより多くが盛り込まれます。
+ 特定のパフォーマンス、コンプライアンス、セキュリティ、およびユーザーインターフェイス (UI) テストのためのステージング環境の追加
+ アプリケーションコードに加え、インフラストラクチャおよび設定コードのユニットテスト
+ コードレビュー、問題の追跡、イベント通知などの他のシステムやプロセスとの統合
+ データベーススキーマの移行との統合 (該当する場合)
+ 監査およびビジネス上の承認のための追加ステップ
複雑な複数環境の CI/CD パイプラインを持つ最も成熟した組織であっても、改善を求め続けています。DevOps は目的地ではなく、道のりです。パイプラインに関するフィードバックは継続的に収集され、スピード、スケール、セキュリティ、信頼性の改善は、開発チームのさまざまな部分の間のコラボレーションとして実現されます。
# チーム
AWS では、CI/CD 環境を実装するために、アプリケーションチーム、インフラストラクチャチーム、ツールチームの 3 つのデベロッパーチームを編成することを推奨しています (下の図を参照)。この組織は、急速に変化するスタートアップ、大規模なエンタープライズ組織、および Amazon 自身で構築され、適用されてきた一連のベストプラクティスを示しています。チームは、2 枚のピザが十分な食事となるグループ、すなわち約 10～12 人よりも大きくするべきではありません。これは、グループサイズが拡大し、コミュニケーション経路が増加するにつれて有意義な会話が限界に達するというコミュニケーションのルールに従っています。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image7.png)
*アプリケーション、インフラストラクチャ、およびツールチーム*
## アプリケーションチーム
アプリケーションチームは、アプリケーションを作成します。アプリケーションデベロッパーは、バックログ、ストーリー、およびユニットテストを担当し、指定されたアプリケーションターゲットに基づいて機能を開発します。このチームの組織上の目標は、デベロッパーがコア以外のアプリケーションタスクに費やす時間を最小限に抑えることです。
アプリケーションチームは、アプリケーション言語における機能的なプログラミングスキルを持つだけでなく、プラットフォームスキルとシステム構成の理解を持ち合わせる必要があります。これにより、チームは機能の開発およびアプリケーションの強化のみに集中することができます。
## インフラストラクチャチーム
インフラストラクチャチームは、アプリケーションの実行に必要なインフラストラクチャを作成および構成するコードを記述します。このチームは、AWS CloudFormation などの ネイティブ AWS ツール、または Chef、Puppet、Ansible などの汎用ツールを使用することがあります。インフラストラクチャチームは、必要なリソースの指定を担当し、アプリケーションチームと密接に連携します。インフラストラクチャチームは、小規模なアプリケーションでは 1 人または 2 人 のみで構成されることがあります。
チームには、AWS CloudFormation や HashiCorp Terraform などのインフラストラクチャプロビジョニング手法に関するスキルが必要です。また、チームは、Chef、Ansible、Puppet、Salt などのツールを使用した構成オートメーションのスキルを高める必要もあります。
## ツールチーム
ツールチームは、CI/CD パイプラインを構築および管理します。このチームは、パイプラインを構成するインフラストラクチャとツールを担当します。このチームは「2 枚のピザ」チームの一部ではありませんが、組織内のアプリケーションおよびインフラストラクチャチームによって使用されるツールを作成します。組織は、ツールチームがアプリケーションチームおよびインフラストラクチャチームの成熟の一歩先を行くように、ツールチームを継続的に成熟させる必要があります。
ツールチームは、CI/CD パイプラインのすべてのパートを構築して統合するためのスキルを備えなければなりません。これには、ソース管理リポジトリ、ワークフローエンジン、ビルド環境、テストフレームワーク、およびアーティファクトリポジトリの構築が含まれます。このチームは、AWS CodeStar、AWS CodePipeline、AWS CodeCommit、AWS CodeDeploy、AWS CodeBuild、AWS CodeArtifact などのソフトウェアに加え、Jenkins、GitHub、Artifactory、TeamCity およびその他の類似ツールを実装することも選択できます。これを DevOps チームと呼ぶ組織もありますが、AWS はこれを推奨せず、DevOps をソフトウェアデリバリーにおける人材、プロセス、ツールの総体として考えるよう推奨しています。
# 継続的インテグレーションと継続的デリバリーにおけるテストステージ
3 つの CI/CD チームは、CI/CD パイプラインの様々なステージでソフトウェア開発ライフサイクルにテストを組み込む必要があります。全体として、テストはできるだけ早期に開始する必要があります。以下に示すテストのピラミッドは、*Succeeding with Agile* で Mike Cohn により提示されている概念です。これは、テストのコストとスピードとの関係において、さまざまなソフトウェアテストを示しています。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/image8.png)
*CI/CD テストのピラミッド*
ユニットテストは、ピラミッドの底にあります。これらは、実行が最も高速で、最も低コストです。したがって、ユニットテストはテスト戦略の大半を占める必要があります。目安としては、約 70% です。このフェーズで発見されたバグは迅速かつ安価に修正できるため、ユニットテストにはほぼ完全なコードカバレッジが必要です。
サービス、コンポーネント、および統合テストは、ピラミッドでユニットテストの上に位置します。これらのテストには詳細な環境が必要なため、インフラストラクチャ要件においてコストが高くなり、実行が遅くなります。次のレベルは、パフォーマンスとコンプライアンスのテストです。これらは、本稼働品質の環境を必要とし、さらにコストが高くなります。UI およびユーザー受け入れテストは、ピラミッドの最上部にあり、同様に本稼働品質の環境を必要とします。
これらのすべてのテストは、高品質なソフトウェアを保証するための完全な戦略の一部です。しかし、開発スピードのためには、ピラミッドの下半分のテストの数とカバレッジが重要視されます。
以下のセクションでは、CI/CD のステージについて説明します。
## ソースのセットアップ
プロジェクトの開始時には、未処理のコードと設定、およびスキーマの変更を保存できるソースをセットアップすることが不可欠です。ソースステージでは、GitHub または AWS CodeCommit などでホストされているソースコードリポジトリを選択します。
## ビルドの設定と実行
ビルドのオートメーションは、CI プロセスにとって不可欠です。ビルドのオートメーションを設定する際、最初のタスクは適切なビルドツールを選択することです。次のようなビルドツールが多数あります。
+ Ant for Java、Maven for Java、Gradle for Java
+ Make for C/C\$1\$1
+ Grunt for JavaScript
+ Rake for Ruby
お客様にとって最適なビルドツールは、プロジェクトのプログラミング言語やチームのスキルセットによって異なります。ビルドツールを選択したら、すべての依存関係をビルドスクリプトおよびビルドステップに明確に定義する必要があります。また、最終的なビルドアーティファクトのバージョンを作成することもベストプラクティスです。これにより、デプロイおよび問題の追跡が容易になります。
## 構築
ビルドステージでは、ビルドツールはソースコードリポジトリへの変更を入力として受け取り、ソフトウェアをビルドし、次のタイプのテストを実行します。
**ユニットテスト** – コードの特定のセクションをテストして、期待されていることをコードが実行することを確認します。ユニットテストは、開発フェーズでソフトウェアデベロッパーが実行します。このステージでは、静的コード分析、データフロー分析、コードカバレッジ、およびその他のソフトウェア検証プロセスを適用することができます。
**静的コード分析** – このテストは、ビルドおよびユニットテストの後にアプリケーションを実際に実行することなく実施されます。この分析は、コーディングエラーおよびセキュリティホールを見つけるのに役立ち、コーディングガイドラインへの準拠を確認することもできます。
## ステージング
ステージングフェーズでは、最終的な本稼働環境を反映した完全な環境が作成されます。以下のテストが実行されます:
**統合テスト** – ソフトウェア設計に対してコンポーネント間のインターフェイスを検証します。統合テストは、反復的なプロセスであり、堅牢なインターフェイスおよびシステムの整合性の構築を容易にします。
**コンポーネントテスト** – さまざまなコンポーネント間のメッセージの受け渡しとその結果をテストします。このテストの主な目的は、コンポーネントテストにおける冪等性を確保することである場合があります。テストには、非常に大きなデータボリューム、または境界条件や異常な入力が含まれる可能性があります。
**システムテスト** – システムテストをエンドツーエンドでテストし、ソフトウェアがビジネス要件を満たしているかどうかを確認します。このテストには、ユーザーインターフェイス (UI)、API、バックエンドロジック、および終了状態のテストが含まれる場合があります。
**パフォーマンステスト** – 特定のワークロードで実行する際のシステムの応答性と安定性を判定します。パフォーマンステストは、スケーラビリティ、信頼性、リソース使用状況など、システムのその他の品質属性を調査、測定、または検証するためにも使用されます。パフォーマンステストのタイプには、ロードテスト、ストレステスト、スパイクテストなどが含まれます。パフォーマンステストは、事前定義された基準に対するベンチマークに使用されます。
**コンプライアンステスト** – コード変更が機能以外の仕様や規定の要件に準拠しているかどうかを確認します。これにより、定義済みの基準を実装し満たしているかどうかを判定します。
**ユーザー受け入れテスト** – エンドツーエンドのビジネスフローを検証します。このテストは、ステージング環境でエンドユーザーにより実行され、システムが要件仕様書の要件を満たしているかどうかを確認します。通常、お客様はこのステージにアルファテストおよびベータテストの方法論を採用しています。
## 本稼働
最後に、これまでのテストに合格した後に、本稼働環境でステージングフェーズが繰り返されます。このフェーズでは、コードを本稼働環境全体にデプロイする前に、新しいコードをサーバーの小さなサブセット、あるいは 1 つのサーバーや 1 つの AWS リージョン のみにデプロイすることで最終的な *canary テスト*を完了することができます。本稼働環境に安全にデプロイする方法の詳細については、「[デプロイ方法](deployment-methods.md)」のセクションで説明しています。
次のセクションでは、これらのステージとテストを組み込むためにパイプラインを構築する方法について説明します。
## パイプラインの構築
このセクションでは、パイプラインの構築について説明します。まず、CI に必要なコンポーネントだけでパイプラインを確立し、その後より多くのコンポーネントとステージを使用した継続的デリバリーパイプラインに移行します。また、このセクションでは、大規模なプロジェクト向けに AWS Lambda 関数と手動承認を使用する方法、複数のチーム、ブランチ、および AWS リージョン の計画方法についても説明します。
# 継続的インテグレーションのための実用最小限のパイプラインから開始する
継続的デリバリーへ向けた組織の歩みは、実用最小限のパイプライン (MVP) から始まります。「[継続的インテグレーションと継続的デリバリーの実装](implementing-continuous-integration-and-continuous-delivery.md)」で説明したように、チームは、コードスタイルのチェックやデプロイのない単一のユニットテストを実行するパイプラインの実装などの非常にシンプルなプロセスから開始することができます。
主なコンポーネントは、継続的デリバリーのオーケストレーションツールです。このパイプラインの構築を支援するために、Amazon は [AWS CodeStar](https://aws.amazon.com/codestar) を開発しました。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/aws-codestar-setup.png)
* AWS CodeStar 設定ページ*
AWS CodeStar では、AWS CodePipeline、AWS CodeBuild、AWS CodeCommit、AWS CodeDeploy を使用して、セットアッププロセス、ツール、テンプレート、ダッシュボードが統合されています。AWS CodeStar は、AWS でアプリケーションを迅速に開発、構築、およびデプロイするために必要なすべてを提供します。これにより、お客様のコードのリリースの高速化が可能になります。既に AWS マネジメントコンソールに精通し、より高いレベルの制御を求めるお客様は、最適なデベロッパーツールを手動で設定し、必要に応じて個々の AWS サービスをプロビジョンできます。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codestar-dashboard.png)
* AWS CodeStar ダッシュボード*
AWS CodePipeline は、迅速かつ信頼性の高いアプリケーションおよびインフラストラクチャの更新のために、AWS CodeStar または AWS マネジメントコンソールを通じて使用できる CI/CD サービスです。AWS CodePipeline は、お客様の定義するリリースプロセスモデルに基づいて、コードの変更があるたびに、コードの構築、テスト、デプロイを実施します。これにより、機能と更新をすばやく、信頼性の高い方法でデリバリーできます。GitHub などの広く利用されているサードパーティーサービス用の構築済みプラグインを使用したり、独自のカスタムプラグインをリリースプロセスの任意のステージに統合したりすることで、エンドツーエンドソリューションを簡単に構築できます。AWS CodePipeline では、実際に使用した分に対してのみお支払いいただきます。前払い金や長期契約はありません。
AWS CodeStar と AWS CodePipeline のステップは、 [ソース、ビルド、ステージング、および本稼働の CI/CD ステージ](testing-stages-in-continuous-integration-and-continuous-delivery.md)に直接マッピングされます。継続的デリバリーが望ましいですが、ソースレポジトリをチェックしてビルドアクションを実行する単純な 2 ステップパイプラインから開始することができます。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-source-build.png)
*AWS CodePipeline — ソースステージとビルドステージ*
AWS CodePipeline では、ソースステージは GitHub、AWS CodeCommit、および Amazon Simple Storage Service (Amazon S3) からの入力を受け入れることができます。ビルドプロセスの自動化は、継続的デリバリーを実装して継続的デプロイに移行するための重要な最初のステップです。ビルドアーティファクト作成への人的関与を排除することにより、チームの負担を軽減し、手作業のパッケージングによるエラーを最小限に抑え、消費可能なアーティファクトのより頻繁なパッケージ化を開始できます。
AWS CodePipeline は、フルマネージド型ビルドサービスである AWS CodeBuild とシームレスに連携するため、コードをパッケージ化しユニットテストを実行するパイプラインに容易にビルドステップを設定できます。AWS CodeBuild により、ビルドサーバーのプロビジョン、管理、またはスケールが不要になります。AWS CodeBuild では、スケールが継続的に行われ、複数のビルドが同時に実行されます。ビルドの実行までキューを待つ必要はありません。AWS CodePipeline は、Jenkins、Solano CI、TeamCity などのビルドサーバーとも統合されています。
例えば、以下のビルドステージでは、3 つのアクション (ユニットテスト、コードスタイルチェック、およびコードメトリクス収集) が並行して実行されます。AWS CodeBuild を使用することで、ロードを処理するためにビルドサーバーを構築またはインストールする必要なく、これらのステップを新しいプロジェクトとして追加できます。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-build-functionality.png)
*AWS CodePipeline — ビルド機能*
図 *AWS CodePipeline — ソースおよびビルドステージ*に示されているソースおよびビルドステージは、サポートプロセスとオートメーションとともに、継続的インテグレーションへのチーム移行を支援します。この成熟度では、デベロッパーはビルドおよびテスト結果に定期的に注意を払う必要があります。また、デベロッパーは健全なユニットテスト基盤を成長させ、保守する必要もあります。これにより、チーム全体の CI/CD パイプラインへの信頼が増し、さらなる導入が支持されるようになります。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-stages.png)
*AWS CodePipeline ステージ*
# 継続的デリバリーパイプライン
継続的インテグレーションパイプラインを実装し、サポートプロセスを確立した後、チームは継続的デリバリーパイプラインへの移行を開始することができます。この移行には、チームがアプリケーションの構築およびデプロイの両方を自動化することが必要になります。
継続的デリバリーパイプラインは、ステージングおよび本稼働ステップが存在することを特徴とします。この本稼働ステップは、手動承認後に実行されます。
継続的インテグレーションパイプラインを構築したのと同様、チームは、デプロイスクリプトを記述することで継続的デリバリーパイプラインの構築を段階的に開始することができます。
アプリケーションのニーズに応じて、いくつかのデプロイステップを既存の AWS のサービスを使用して抽象化することができます。例えば、AWS CodePipeline は、Amazon EC2 インスタンスおよびオンプレミスで実行中のインスタンスへのコードデプロイを自動化するサービスである AWS CodeDeploy、Chef を使用してアプリケーションを操作しやすくする設定管理サービスである AWS OpsWorks、およびウェブアプリケーションおよびサービスのデプロイとスケーリングのためのサービスである AWS Elastic Beanstalk と直接統合されています。
AWS は、AWS CodeDeploy をお客様のインフラストラクチャおよびパイプラインに実装し統合する方法に関する詳細な[ドキュメント](https://docs.aws.amazon.com/codepipeline/latest/userguide/getting-started-w.html#getting-started-w-create-deployment)を提供しています。
チームがアプリケーションのデプロイの自動化に成功した後、様々なテストでデプロイステージを拡張できます。例えば、Ghost Inspector、Runscope などのサービスを使用して、すぐに使用開始可能なその他の統合を追加することができます。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codepipeline-code-test-deployment.png)
*AWS CodePipeline — デプロイステージでのコードテスト*
# Lambda アクションの追加
AWS CodeStar と AWS CodePipeline は、[AWS Lambda との統合](https://docs.aws.amazon.com/codepipeline/latest/userguide/how-to-lambda-integration.html)をサポートしています。この統合により、環境でのカスタムリソースの作成、サードパーティーシステム (Slack など) との統合、および新しくデプロイされた環境のチェックの実行など、幅広いタスクを実装できます。
Lambda 関数は、以下のタスクを実行するために CI/CD パイプラインで使用できます。
+ AWS CloudFormation テンプレートを適用または更新することで、環境に対する変更を展開する。
+ AWS CloudFormation を使ってパイプラインの 1 つのステージでリソースをオンデマンドで作成し、別のステージで削除する。
+ [正規名レコード](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html) (CNAME) 値をスワップする Lambda 関数 を使用して、アプリケーションバージョンをゼロダウンタイムで AWS Elastic Beanstalk にデプロイする。
+ Amazon Elastic Container Service (ECS) の Docker インスタンスにデプロイする。
+ AMI スナップショットを作成し、構築またはデプロイの前にリソースをバックアップする。
+ インターネットリレーチャット (IRC) クライアントにメッセージを投稿する等、サードパーティー製品によってパイプラインに統合を追加する。
# 手動承認
必要な AWS Identity and Access Management (IAM) 権限を持つユーザーがアクションを承認または拒否できるように、パイプラインの処理を停止するところで承認アクションをパイプラインのステージに追加することができます。
アクションが承認されている場合、パイプラインの処理は再開されます。アクションが拒否された場合、またはパイプラインがそのアクションに到達して停止してから 7 日以内に誰もアクションを承認または拒否しない場合、結果はアクションの失敗と同じとなり、パイプラインの処理は続行しません。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/codedeploy-manual-approvals.png)
*AWS CodeDeploy — 手動承認*
# CI/CD パイプラインにおけるインフラストラクチャのコード変更のデプロイ
AWS CodePipeline ではパイプラインのどのステージにおいても AWS CloudFormation をデプロイアクションとして選択することができます。その後、スタックの作成や削除、[変更セット](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3952)の作成や実行など AWS CloudFormation で実施したい特定のアクションを選択します。[スタック](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-whatis-concepts.html#d0e3929)は、AWS CloudFormation の概念であり、関連する AWS リソースのグループを表します。Infrastructure as Code をプロビジョニングするためのさまざまな方法がありますが、AWS CloudFormation は、最も包括的な AWS リソースのセットをコードとして記述できる、スケーラブルで完全なソリューションとして AWS が推奨する包括的なツールです。AWS は、AWS CodePipeline プロジェクトで AWS CloudFormation を使用して、[インフラストラクチャの変更とテストを追跡する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/continuous-delivery-codepipeline.html)ことを推奨しています。
# サーバーレスアプリケーションの CI/CD
AWS CodeStar、AWS CodePipeline、AWS CodeBuild、および AWS CloudFormation を使用して、サーバーレスアプリケーション用の CI/CD パイプラインを構築することもできます。サーバーレスアプリケーションは、[Amazon Cognito](https://aws.amazon.com/cognito)、Amazon S3、Amazon DynamoDB などのマネージドサービスをイベント駆動型サービスと統合し、AWS Lambda はサーバーの管理を必要としない方法でアプリケーションをデプロイします。サーバーレスアプリケーションのデベロッパーは、AWS CodePipeline、AWS CodeBuild、および AWS CloudFormation の組み合わせを使用して、AWS Serverless Application Model を使用して構築されたテンプレートで表現されるサーバーレスアプリケーションの構築、テスト、およびデプロイを自動化できます。詳細については、AWS Lambda のドキュメント、[Lambda ベースのアプリケーションのデプロイを自動化する](https://docs.aws.amazon.com/lambda/latest/dg/automating-deployment.html)を参照してください。
また、AWS Serverless Application Model パイプライン (AWS SAM パイプライン) を使用して、組織のベストプラクティスに従った安全な CI/CD パイプラインを作成することもできます。AWS SAM パイプラインは、AWS SAM CLI の新機能で、デプロイ頻度の加速、変更のリードタイムの短縮、デプロイエラーの低減などの CI/CD の利点を数分でご利用いただけるようになります。AWS SAM パイプラインには、AWS CodeBuild/CodePipeline 向けに、AWS のデプロイのベストプラクティスに従ったデフォルトのパイプラインテンプレートが用意されています。詳細およびチュートリアルの表示については、ブログ [Introducing AWS SAM Pipelines](https://aws.amazon.com/blogs/compute/introducing-aws-sam-pipelines-automatically-generate-deployment-pipelines-for-serverless-applications/) を参照してください。
# 複数のチーム、ブランチ、AWS リージョン用のパイプライン
大規模なプロジェクトの場合、複数のプロジェクトチームでさまざまなコンポーネントに取り組むことがよくあります。複数のチームが 1 つのコードリポジトリを使用する場合、各チームが独自のブランチを持つようにマップできます。プロジェクトの最終マージには、統合ブランチまたはリリースブランチも必要です。サーバー指向アーキテクチャまたはマイクロサービスアーキテクチャを使用する場合、各チームは独自のコードリポジトリを持つことができます。
最初のシナリオで、単一のパイプラインを使用した場合、1 つのチームがパイプラインをブロックすることで他のチームの進捗に影響が及ぶ可能性があります。チームブランチ用に特定のパイプラインを作成し、最終製品のデリバリー用に別のリリースパイプラインを作成することをお勧めします。
# AWS CodeBuild によるパイプライン統合
AWS CodeBuild は、組織がほぼ無制限の規模で可用性の高いビルドプロセスを構築できるよう設計されています。AWS CodeBuild は、多くの一般的な言語向けのクイックスタート環境に加えて、指定した Docker コンテナを実行する機能を提供します。
AWS CodeCommit、AWS CodePipeline、AWS CodeDeploy に加え、Git および CodePipeline の Lambda アクションとの緊密な統合の利点を持ち、CodeBuild ツールは非常に柔軟性があります。
ソフトウェアは、ビルド前後のアクションを含む各ビルドステップを指定する `buildspec.yml` ファイルや CodeBuild ツールを通して指定されたアクションを組み込んで構築することができます。
CodeBuild ダッシュボードを使用して、各ビルドの詳細な履歴を表示できます。イベントは、Amazon CloudWatch Logs ログファイルとして保存されます。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/cloudwatch-logs-log-files.png)
*AWS CodeBuild の CloudWatch Logs ログファイル*
# Jenkins によるパイプライン統合
Jenkins ビルドツールを使用して、[デリバリーパイプラインを作成する](https://www.jenkins.io/doc/book/pipeline/getting-started/)ことができます。これらのパイプラインは、継続的デリバリーのステージを実装するためのステップを定義する標準的なジョブを使用します。しかし、このアプローチは、大規模なプロジェクトには最適ではない可能性があります。これは、Jenkins の再起動時にパイプラインの現在の状態が維持されず、手動承認の実装が容易ではなく、複雑なパイプラインの状態を追跡することが困難になる可能性があるためです。
代わりに、AWS は、[AWS CodePipeline Plugin](https://wiki.jenkins-ci.org/display/JENKINS/AWS+CodePipeline+Plugin) を使用して Jenkins による継続的デリバリーを実装することをお勧めします。このプラグインにより、Groovy のようなドメイン固有言語を使用して複雑なワークフローを記述することができ、複雑なパイプラインをオーケストレートするために使用できます。AWS CodePipeline Plugin の機能は、パイプラインで定義された現在の進行状況を視覚化する [Pipeline Stage View Plugin](https://plugins.jenkins.io/aws-codepipeline/)、異なるブランチのビルドをグループ化する [Pipeline Multibranch Plugin](https://plugins.jenkins.io/workflow-multibranch/) などのサテライトプラグインを使用することで拡張できます。
AWS は、パイプラインの設定を *Jenkinsfile* に保存し、ソースコードリポジトリにチェックインしておくことをお勧めします。これにより、パイプラインコードの変更を追跡することができます。また、Pipeline Multibranch Plugin を使用する際にこれはさらに重要になります。また、AWS はパイプラインをステージに分けることをお勧めします。これにより、パイプラインステップが論理的にグループ化され、Pipeline Stage View Plugin でパイプラインの現在の状態を視覚化できるようになります。
以下の図は、Pipeline Stage View Plugin で視覚化された 4 つの定義済みステージを備えた Jenkins パイプラインのサンプルを示しています。
![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/practicing-continuous-integration-continuous-delivery/images/defined-stages-of-jenkins.png)
*Pipeline Stage View Plugin で視覚化された Jenkins パイプラインの定義済みステージ*