4.1CI/CD パイプライン

コードの変更を自動でビルド・テスト・デプロイする仕組みが CI/CD です。AWS では CodePipeline が全体を編成し、各段階を専用サービスが担います。

4.1.1パイプラインの段階

• CodePipeline：ソース→ビルド→テスト→デプロイの段階全体を編成する。
• CodeBuild：ソースをビルド/テストする。手順は buildspec.yml に記述する。
• CodeDeploy：EC2/オンプレ/Lambda/ECS へデプロイする。手順は appspec に記述。
• CodeCommit は Git リポジトリ（外部 Git も可）。コミットがパイプラインを起動する。※CodeCommit は 2024 年 7 月以降 新規顧客の受付を終了（既存は継続）。新規は GitHub 等＋CodeConnections が一般的。

CI/CD の肝は「役割の切り分け」です。CodePipeline はステージ（ソース→ビルド→テスト→デプロイ）を編成するだけで、実際の処理は各サービスに委譲します。ビルドとテストは CodeBuild が buildspec.yml の手順（install/pre_build/build/post_build フェーズ）で実行し、生成物（アーティファクト）を S3 に置いて次ステージへ渡します。デプロイは CodeDeploy が appspec の指示（どのファイルをどこへ・フック処理）で行います。各ステージ間はアーティファクトで連携し、承認アクションを挟めば手動承認を要求できます。ソースには CodeCommit のほか GitHub などの外部 Git も使え、コミットや Pull Request が トリガー となってパイプラインが自動起動します。失敗したステージで止まる（=不良コードが本番に届かない）のが CI/CD の安全性です。

CodeBuild をもう少し掘り下げます。ビルドは隔離されたコンテナで実行され、実行環境（イメージ・コンピュートサイズ）や環境変数を指定できます。パスワードや API キーは平文の環境変数に置かず、Secrets Manager / Parameter Store から参照します（前章のシークレット管理と一貫）。依存関係のダウンロードを短縮するキャッシュ（S3 やローカル）や、複数フェーズの並列実行、テスト結果レポートにも対応します。CodePipeline では1つのステージに複数アクションを置いて並列実行でき、別リージョン/別アカウントへのデプロイ（クロスアカウント）も組めます。ソース変更の検知は、ポーリングよりWebhook/イベント駆動（EventBridge）が推奨で、無駄なくパイプラインを起動します。ビルド成果物やキャッシュ、アーティファクトの保管先は基本的に S3 です。

4.1.2依存パッケージと開発者シェル（CodeArtifact・CloudShell）

CI/CD のビルドでは、外部の公開リポジトリから依存パッケージを取得しますが、社内共有や可用性・セキュリティの観点でこれを内製化したいことがあります。AWS CodeArtifact は マネージドなパッケージリポジトリで、npm・pip・Maven・NuGet などに対応し、公開リポジトリのプロキシ/キャッシュとして機能しつつ、組織内のプライベートパッケージを共有できます。CodeBuild から CodeArtifact を参照すれば、バージョンを固定し、外部障害や不正パッケージの影響を抑えられます。一方、ブラウザだけで AWS CLI をすぐ使いたいときは AWS CloudShell が便利です。CloudShell は認証済み・AWS CLI/SDK 同梱のブラウザシェルで、ローカルにキーや CLI を用意せずに、その場でコマンドを実行できます。判断の勘所は「依存パッケージの共有/プロキシ＝CodeArtifact」「ブラウザから即 CLI 実行＝CloudShell」です。

4.1.3この節のまとめ

• CodePipeline（編成）／CodeBuild（buildspec）／CodeDeploy（appspec）
• コミットが自動でビルド→テスト→デプロイを起動