AWSのCI/CDパイプラインと開発者ツール
継続的インテグレーションと継続的デリバリーの考え方を整理し、CodePipeline、CodeBuild、CodeDeployなどAWS開発者ツールの役割と連携を学びます。
AWSのCI/CDパイプラインと開発者ツール
アプリケーションの変更を安全に届けるには、ソースコードを書くだけでなく、ビルド、テスト、デプロイ、リリース後の確認までを繰り返し実行できる仕組みが必要です。手順を人が毎回手作業で行うと、コマンドの実行漏れや環境ごとの操作差が生じ、変更の検証にも時間がかかります。
CI/CDは、ソフトウェア変更を継続的に検証し、リリース可能な状態へ運ぶための考え方と自動化です。AWSでは、CodePipelineを中心にCodeBuild、CodeDeploy、ソース管理やパッケージ管理のサービスを組み合わせて実現できます。これらは役割の異なる部品であり、CodePipelineだけがビルドから実行環境の運用まですべてを行うわけではありません。
開発から運用までの流れ
一般的なソフトウェアのリリースでは、開発者がソースを変更し、その変更をビルドしてテストします。検証を通過した成果物をテスト環境や本番環境へデプロイし、利用者へリリースした後も、稼働状況を監視して次の改善につなげます。CI/CDはこのうち、変更を統合して確かめ、環境へ届ける工程を繰り返し可能にします。
たとえば、植物の在庫を管理するWebアプリケーションで、開発者が商品検索機能を変更したとします。Gitリポジトリへの変更を契機にパイプラインを開始し、アプリケーションをビルドして単体テストを実行します。成功した成果物をテスト環境に配置して動作を確認し、必要であれば担当者の承認を挟んでから本番環境へ進めます。ビルドやテストに失敗した変更は、後続のリリース工程へ進ませず、開発者が修正できるよう結果を知らせます。
パイプラインは、必ずしも「ソース、ビルド、テスト、デプロイ」という同じ形に固定されません。アプリケーションの構成やリスクに応じて、静的解析、統合テスト、複数環境への段階的な展開、承認、リリース後の動作確認などを加えたり、省いたりできます。
CIとCD
継続的インテグレーション（CI）
**継続的インテグレーション（Continuous Integration）**は、開発者が行った変更を共有ソースへ継続的に統合し、自動ビルドやテストによって検証する開発の進め方です。小さな変更を頻繁に統合し、失敗を早く見つけることで、長期間統合されていないコード同士の衝突や、問題箇所の特定にかかる負担を小さくできます。
CIパイプラインでは、ソース更新のたびにコンパイルやパッケージ化を行い、単体テスト、コード品質チェックなどを実行できます。失敗を検知したら、その実行結果を開発者へ伝えます。CIが保証するのは、設定されたチェックが実行されたことです。テスト内容が不十分なら、実行が成功してもアプリケーション全体の正しさが保証されるわけではありません。
継続的デリバリーと継続的デプロイメント
**継続的デリバリー（Continuous Delivery）**は、変更を自動でビルド・テストし、本番へリリースできる状態に保つ考え方です。組織の運用方針に応じて、本番反映の直前に手動承認を置くことがあります。
**継続的デプロイメント（Continuous Deployment）**は、検証に成功した変更を、追加の手動操作を挟まず本番環境まで自動で配備する進め方を指します。どちらもデプロイ手順の自動化により、リリースの繰り返しやすさを高め、人為的な操作ミスを減らします。実務上はCDを「デリバリー」と「デプロイメント」の両方の意味で使う場合もあります。試験問題では、手動承認を残すか、本番まで自動的に進めるかという要件に注目してください。
CodePipelineのステージとアクション
AWS CodePipelineは、ソフトウェア変更がリリース工程を通る順番を定義する継続的デリバリーサービスです。パイプラインは複数のステージで構成され、各ステージには実行単位であるアクションを配置します。アクションにはソース取得、ビルド、テスト、デプロイ、承認、Lambda関数などの呼び出しがあります。同じステージ内のアクションは、設定に応じて順番に実行したり、並列に実行したりできます。
各工程で生成・受け渡しするファイルやソース一式をアーティファクトと呼びます。たとえば、ソースアクションが取得した入力や、CodeBuildが出力するパッケージが後続アクションへの受け渡し対象です。テスト工程が成功した成果物を次の環境へ渡すことで、検証したものと同じビルド結果を後続環境で使えます。
ステージは、開発環境・テスト環境・本番環境のように、工程や環境の境界を表すために使えます。手動承認アクションを本番デプロイ前に配置すれば、パイプラインをそこで停止し、権限を持つ担当者が承認した場合にだけ続行させられます。拒否された場合や所定期間内に応答がない場合、その実行は先へ進みません。
CodePipelineは、各アクションを実行するサービスや外部ツールと連携して全体を制御します。ビルド処理そのものはCodeBuildなどのアクションプロバイダーが担い、デプロイ処理はCodeDeployやCloudFormationなどに任せられます。パイプラインの実行履歴から、どのステージやアクションが成功・失敗したかを追跡し、失敗した工程を調査できます。
AWS開発者ツールの役割
| サービス | 主な役割 | CI/CDでの位置づけ |
|---|---|---|
| AWS CodePipeline | リリース工程の編成と実行 | ソース変更を受け取り、ビルド・テスト・承認・デプロイのアクションを接続する |
| AWS CodeBuild | ソースコードのビルド、テスト、成果物の作成 | 指定されたビルド環境とビルド仕様に従ってコマンドを実行する |
| AWS CodeDeploy | アプリケーションのデプロイ | Amazon EC2、オンプレミスインスタンス、AWS Lambda、Amazon ECSへのデプロイを自動化する |
| AWS CodeCommit | Gitベースのソースリポジトリのホスト | コード、ブランチ、コミット履歴を管理し、パイプラインのソースとして利用する |
| AWS CodeConnections | 外部コードプロバイダーとの接続 | GitHub、GitLab、BitbucketなどのリポジトリをAWSサービスから利用する接続を提供する |
| AWS CodeArtifact | ソフトウェアパッケージの保管・共有 | ビルドで使う依存パッケージや内部ライブラリを管理する |
CodeBuildでビルドとテストを行う
CodeBuildは、ソースコードをコンパイルし、テストを実行して、配布可能な成果物を作るマネージドビルドサービスです。プロジェクトでソース、ビルド環境、成果物の出力先を設定します。リポジトリに置くbuildspec.ymlなどのビルド仕様には、依存関係の取得、テスト、ビルド、アーティファクトの指定を記述できます。
ビルド仕様にテストコマンドを記述すれば、CodeBuildのビルド中にテストを実行できます。対応するテスト結果ファイルをレポートとして記録し、実行ごとの結果や失敗したテストの調査に利用することもできます。テストが失敗したときにパイプラインを後続へ進めない構成にするには、CodePipeline側でアクションの成功・失敗を後続処理の条件に反映させます。
CodeBuildはCodePipelineに組み込まなくても、単独でビルドを実行できます。パイプラインから呼び出す場合は、CodePipelineのサービスロールにCodeBuildのビルドを開始・参照する許可が必要です。また、ビルド環境からS3やデータベースなどのAWSリソースへアクセスする必要があるなら、CodeBuildプロジェクトに割り当てたサービスロールへ、その操作に必要な権限を設定します。
CodeDeployでアプリケーションを配備する
CodeDeployは、アプリケーションの新しいリビジョンを指定したデプロイ先へ配置するサービスです。Amazon EC2やオンプレミスのインスタンスへのファイル配置だけでなく、Lambda関数やAmazon ECSサービスのデプロイも扱えます。対象環境に応じてデプロイグループやデプロイ設定を構成し、どのリソースを更新するか、成功・失敗をどう判断するかを定めます。
CodeDeployはパイプラインの代わりではなく、デプロイ工程を担当する選択肢です。CodePipelineからCodeDeployアクションを呼び出すと、ソースの取得やテスト、承認などを含む一連の工程をCodePipelineが調整し、CodeDeployが対象アプリケーションを更新します。デプロイ先のサービスやアプリケーションの種類によっては、CodeDeploy以外のデプロイ手段をパイプラインから利用することもできます。
役割のつながりを追う例
植物の在庫管理アプリケーションを、GitHubで管理し、AWS上のLambda関数として公開するとします。CodeConnectionsでリポジトリへの接続を用意し、CodePipelineのソースアクションに対象ブランチを設定します。変更が取り込まれると、CodePipelineはソースを取得してCodeBuildを開始します。CodeBuildはビルド仕様に従ってテストを実行し、成功したコードや成果物を後続アクションに渡します。
テスト環境での確認を終えて担当者が承認すると、CodePipelineはCodeDeployのアクションを開始し、CodeDeployがLambda関数の更新を行います。更新後はヘルスチェックやアプリケーション側の動作確認を行い、問題があれば実行履歴や各サービスのログを調べます。この例でCodePipelineは「どの順番で何を行うか」を管理し、CodeBuildは「何をビルド・テストするか」を実行し、CodeDeployは「どこへどう配備するか」を担当しています。
同じ開発フローでも、実行先がEC2ならインスタンス群への配備、ECSならサービスの更新など、デプロイアクションとその設定は変わります。ビルドしたファイルを直接EC2へコピーするのか、コンテナイメージを作るのか、Lambdaのコードをパッケージ化するのかに応じて、成果物の形式やデプロイ方法を合わせる必要があります。
パイプラインとデプロイ先を混同しない
CodePipeline、CodeBuild、CodeDeployは、アプリケーションを作り配備する工程を自動化するサービスです。アプリケーションが稼働するコンピューティング環境そのものではありません。たとえば、Lambda関数、EC2インスタンス、ECSサービス、Elastic Beanstalk環境などは実行先です。どの実行先を使うかによって、必要なビルド成果物やデプロイ方式も異なります。
また、アプリケーションのリリースパイプラインと、AWSインフラを定義・構築する仕組みも区別します。CloudFormationやAWS CDKは、スタックやリソース構成をコードからプロビジョニングするための仕組みです。CodePipelineからCloudFormationのアクションを実行したり、CDK PipelinesでCDKアプリの合成とデプロイを構成したりできますが、これらのIaC機能がCodePipelineと同じ役割になるわけではありません。
自動化するときに設計すること
パイプラインは、手作業をそのまま高速化するだけではありません。どの変更を対象にするか、何をもってテスト成功とするか、本番へ進める条件を何にするかを明確にします。少なくとも次の点を決めます。
- 起動条件：どのリポジトリ、ブランチ、タグ、変更イベントをソースとして扱うか。
- 検証内容：ビルド、単体テスト、統合テスト、脆弱性やコード品質の確認のうち、どれを実行するか。
- 成果物の一貫性：テストしたものと同じ成果物をステージングや本番へ昇格させるか。環境ごとにビルドし直して差異を作らないか。
- リリース境界：開発・テスト・本番の間に承認や段階的な配備を置くか。失敗時に停止・ロールバックする方法があるか。
- 追跡方法：コミットとビルド、テスト、デプロイ結果を関連付け、失敗箇所やリリース内容を追えるか。
各サービスに設定するIAMロールも分けて考えます。CodePipelineのロールは、パイプラインがCodeBuildやデプロイ先などのアクションプロバイダーを呼び出すために使います。CodeBuildのロールはビルド中に必要なAWSリソースへアクセスするために使い、デプロイ先のサービスロールはデプロイ処理に必要な権限を持ちます。開発者や運用者がパイプラインを作成・承認できるIAM権限は、これらのサービス実行ロールとは別のものです。役割に応じた最小限の権限を与え、必要なアクションとリソースに範囲を絞ります。
本番までの自動化を強めるほど、対象ブランチの保護、変更レビュー、依存パッケージの信頼性、テストの網羅性が重要になります。自動テストが成功したという事実だけで、本番リリースが安全だと自動的に保証されるわけではありません。必要なレビューや承認をワークフローに含め、問題を検知したときにどの段階で停止し、どう修復するかを決めます。
試験で整理するポイント
- コードの保管場所を問われたら、GitリポジトリをホストするCodeCommitや、CodeConnections経由で接続した外部プロバイダーを考える。
- ソース変更から工程を順番に進める制御にはCodePipelineを使う。CodePipelineはビルドやデプロイの各サービスを呼び出して工程を編成する。
- ソースをコンパイルし、テストして成果物を作る役割はCodeBuild。具体的なコマンドやフェーズはビルド仕様で定義する。
- EC2、オンプレミス、Lambda、ECSへアプリケーションをデプロイする役割はCodeDeployが候補になる。CodePipelineの工程管理とは役割が異なる。
- 複数段階の検証や本番前の人手承認が要件なら、CodePipelineにテストや承認アクションを含むステージを設計する。
- 継続的デリバリーは本番リリース可能な状態まで自動化し承認を残す構成も含む。継続的デプロイメントは検証後の本番配備まで自動化する。
- 実行先の選択とリリース手順の自動化は別の判断である。LambdaやEC2などは実行環境、CodePipelineなどは開発・配備工程の自動化を担う。
- CodeCommitの新規利用状況は過去に変更があった。AWSは2024年に新規顧客向け提供を停止した後、2025年11月25日から新規顧客にも再び提供している。
公式ドキュメント
重要ポイント
- ▸CIはソース変更を継続的にビルド・テストして統合上の問題を早く見つける取り組みであり、CDは検証済み変更をリリース可能な状態に保つ、または本番まで自動配備する取り組みを指す
- ▸CodePipelineはステージとアクションでリリース手順を編成し、CodeBuildはソースをビルド・テストし、CodeDeployはEC2・オンプレミス・Lambda・ECSへのデプロイを実行する
- ▸パイプライン内の成果物は各工程を受け渡す入力・出力であり、テストや承認などのゲートを通過した変更だけを後続環境へ進められる
- ▸CodeCommitはGitリポジトリをホストし、CodeConnectionsはGitHubなど外部プロバイダーとの接続を提供する。CodeArtifactはソフトウェアパッケージの保管・共有を担う
- ▸CI/CDサービスはデプロイ先の実行環境そのものではない。対象アプリケーションの配置先と、各パイプライン・ビルド・デプロイ用IAMロールの権限を分けて考える
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
IaC / 環境自動化 / コンテナ に関連するトピックを続けて確認できます。