変更要約: in-scope サービス網羅: App Runner, App2Container, AWS Copilot, Serverless Application Repository, CloudShell, AWS CLI/SDK, CodeStar を s3 に追記
1.1CI/CD パイプライン
AWS の CI/CD サービス——CodePipeline（オーケストレーション）、CodeBuild（ビルド/テスト）、CodeCommit（ソース）、CodeArtifact（依存パッケージ）——を理解します。コードからデプロイまでを自動化します。
DevOps の中核は継続的インテグレーション/デリバリー（CI/CD）です。ソース→ビルド→テスト→デプロイをパイプラインで自動化します。
1.1.1CI/CD サービスの構成
- CodePipeline：ステージ（Source/Build/Test/Deploy）をオーケストレーションし、変更で自動起動。
- CodeBuild：buildspec.yml に従いビルド/テストを実行するマネージドなビルドサービス。
- CodeCommit：マネージドな Git リポジトリ（ソース）。GitHub 等も Source に使える。※CodeCommit は 2024 年 7 月以降、新規顧客の受付を終了（既存利用は継続）。新規構成では GitHub 等＋CodeConnections が一般的。
- CodeArtifact：依存パッケージ（npm/pip/Maven 等）を一元管理するアーティファクトリポジトリ。
「パイプラインのオーケストレーション＝CodePipeline」「ビルド/テスト＝CodeBuild（buildspec.yml）」「ソース＝CodeCommit/GitHub」「依存パッケージ管理＝CodeArtifact」 は DOP-C02 で頻出です。手動承認アクションをステージ間に挟めば、本番デプロイ前のゲートを設けられます。
CodeBuild は buildspec.yml にビルド・テスト・成果物のフェーズを定義します。テストを Build ステージに含めると、失敗時にパイプラインが止まり不良なコードのデプロイを防げます。
DOP-C02 では「パイプラインをどう構成し、どこに統制を効かせるか」が問われます。CodePipeline は ステージ（直列）とアクション（ステージ内で並列/直列）で構成され、各ステージ間は アーティファクトストア（S3）を介して成果物を受け渡します。ソースの変更検知は、CodeCommit なら EventBridge、GitHub なら CodeStar Connections（CodeConnections）経由の Webhook で行い、ポーリングより低遅延です。CodeBuild は buildspec.yml の phases（install/pre_build/build/post_build）と artifacts/cache/reports を定義し、特権モードで Docker イメージをビルドしたり、VPC 内のリソースにアクセスしたりできます。マルチアカウント構成では、パイプラインを置く CI/CD アカウントから各環境アカウントのロールを AssumeRole してデプロイするのが定石で、アーティファクトの暗号化に使う KMS キーをクロスアカウントで共有します。CodeArtifact はアップストリームに公開リポジトリ（npm/PyPI など）を設定して透過的にプロキシ・キャッシュでき、社内パッケージと公開パッケージを 1 つのエンドポイントに統合します。
| 役割 | サービス | 要点 |
|---|---|---|
| ステージのオーケストレーション | CodePipeline | 変更検知で自動起動・承認やアクションを配置 |
| ビルド/テスト実行 | CodeBuild | buildspec.yml・特権/VPC・テストレポート |
| ソース管理 | CodeCommit / GitHub | EventBridge or CodeConnections で起動 |
| 依存パッケージ | CodeArtifact | アップストリームで公開リポジトリをプロキシ |
シナリオ：開発・ステージング・本番が別アカウントで、1 本のパイプラインから順にデプロイしたい。→ CI/CD 用アカウントに CodePipeline を置き、各環境アカウントに用意したデプロイ用ロールを AssumeRole。アーティファクトは S3＋KMS で暗号化し、KMS キーポリシーで各アカウントに復号を許可。ステージング→本番の間に 手動承認アクションを挟み、本番アカウントには最小権限のロールだけを与えます。
FAQ：GitHub をソースにするとき、ポーリングと Webhook どちらがよい？ CodeStar Connections（CodeConnections）による Webhook 起動が推奨です。ポーリングは定期チェックのため遅延が出てパイプライン起動が遅れます。Webhook なら push 直後にイベントで起動でき、無駄な実行も減ります。
ひっかけ：「ビルド中に Docker イメージをビルドしたい」のに CodeBuild の特権モード（privileged）を有効にし忘れる構成は失敗します。また CodeArtifact は「依存パッケージ（npm/pip/Maven）」用で、コンテナイメージは ECR が正解——アーティファクトの種類で保管先を取り違えないこと。
1.1.2この節のまとめ
- CI/CD＝CodePipeline（統合）＋CodeBuild（ビルド/テスト）
- ソース＝CodeCommit/GitHub／依存＝CodeArtifact
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. ソース→ビルド→テスト→デプロイのステージを定義し、変更検知で自動的にパイプラインを進めたい。何を使いますか？
Q2. buildspec.yml に従ってビルドとユニットテストを実行するマネージドサービスはどれですか？
Q3. npm や pip などの依存パッケージを一元管理し、ビルドから安全に取得させたい。何を使いますか？