Cloud Service
AWS CodePipeline
ソースからビルド、デプロイまでの一連の CI/CD 工程を自動化するパイプラインオーケストレーションサービス。
- 1.コードの変更を起点に、ビルド・テスト・デプロイを段階的に自動実行する。
- 2.ステージとアクションを組み合わせ、手動承認や並列処理も柔軟に構成できる。
- 3.CodeBuild や CodeDeploy など他サービスを束ね、リリースを標準化・高速化する。
解決する課題
手作業のリリースは、ビルド忘れ・テスト漏れ・デプロイ手順のばらつきといったヒューマンエラーの温床です。CodePipeline はこの一連の流れを自動化します。
- コードの変更を起点(トリガー)に、ビルドからデプロイまでを自動で連鎖実行する
- 手順をパイプライン定義としてコード化・標準化し、誰が実行しても同じ結果になる
- 失敗したステージで自動停止し、問題のある変更が本番へ流れるのを防ぐ
主要概念と用語
- パイプライン: ソースからデプロイまでの一連のワークフロー全体を表す単位
- ステージ: パイプラインを区切る論理的なフェーズ(例: ソース、ビルド、デプロイ)
- アクション: ステージ内で実行される個々の作業(ビルド実行、テスト、承認など)
- アーティファクト: ステージ間で受け渡されるファイル群。多くは S3 バケットに格納される
- トランジション: ステージからステージへ成果物が進む経路。有効化・無効化で流れを制御できる
- プロバイダー: 各アクションを実際に処理するサービス(ソースは CodeCommit や GitHub、ビルドは CodeBuild など)
仕様・制限・クォータ
- パイプラインは複数のステージで構成し、各ステージには1つ以上のアクションを置く
- アクションは直列にも並列にも配置でき、並列アクションはすべて完了するまで次へ進まない
- ステージ間で受け渡すアーティファクトは S3 バケットに保存され、後続アクションが入力として利用する
- 1リージョン・1アカウントあたりのパイプライン数や、同時実行に関するクォータが存在し、引き上げ申請が可能
- アクション種別はソース、ビルド、テスト、デプロイ、承認、呼び出し(Lambda 等)に大別される
内部の仕組み
CodePipeline は自身が処理を行うのではなく、各アクションを外部のプロバイダーに委譲するオーケストレーターです。各アクションの結果(成功・失敗)を受け取り、次のステージへ進めるかどうかを判断します。
- ソースステージで変更を検知すると、対象をアーティファクトとして S3 に格納し、後続へ渡す
- ビルドやデプロイのアクションは CodeBuild・CodeDeploy・CloudFormation などのプロバイダーが実体を処理する
- 変更検知は、定期的なポーリングよりも EventBridge やリポジトリ側の通知によるイベント駆動が推奨される
ソース変更をポーリングで監視するより、EventBridge による検知を使うほうが反応が速く無駄も少なくなります。新規パイプラインでは原則こちらを選びましょう。
設計パターン / ベストプラクティス
- 段階的デプロイ: 開発→ステージング→本番のように環境ごとにステージを分け、各段で検証を挟む
- 手動承認ゲート: 本番デプロイの前に承認アクションを置き、人の確認を必須にする
- パイプライン自体をコード化: 定義を CloudFormation や CDK で管理し、再現性とレビュー可能性を確保する
- 並列アクションで時間短縮: 独立したテストやビルドは並列に並べ、全体のリードタイムを縮める
運用・監視
- 実行履歴: パイプラインの各実行がどのステージで成功・失敗したかをコンソールや API で追跡できる
- 通知: ステージの失敗や承認待ちを EventBridge 経由で検知し、SNS や Chatbot 経由でチームへ知らせる
- 失敗時の切り分け: 失敗したアクションのプロバイダー側ログ(CodeBuild のビルドログ等)を確認する
- 再実行: 失敗したステージから、あるいはパイプライン全体を再実行できる
コスト
料金は主にアクティブなパイプライン数に対して課金される体系です。一定数の無料枠が用意されている一方、実際のビルドやデプロイにかかる費用は CodeBuild の実行時間など各プロバイダー側で別途発生する点に注意します。具体的な金額は変動するため、最新の料金ページで確認してください。
- 使っていないパイプラインは削除して無駄な課金を避ける
- 全体コストはパイプライン本体よりも、ビルド時間やデプロイ先リソースの比重が大きくなりやすい
セキュリティ
- サービスロール: CodePipeline には IAM のサービスロールをアタッチし、必要な権限のみを最小権限で付与する
- アーティファクト保護: ステージ間の成果物が入る S3 バケットは暗号化し、KMS で鍵を管理する
- 承認の統制: 本番への承認アクションを実行できる権限を絞り、誰でも承認できない状態にする
- クレデンシャル排除: パイプライン内でアクセスキーをハードコードせず、ロールで権限を渡す
サービスロールに過剰な権限を与えると、パイプライン経由で想定外のリソースを操作できてしまいます。デプロイ先や参照するバケットに限定しましょう。
Well-Architected の観点
- 運用上の優秀性: リリース手順をコード化・自動化し、手作業によるばらつきとミスを排除する。失敗を早期に検知し、再実行で迅速に回復できる
- 変更を小さく頻繁にデプロイする文化を支え、パイプライン定義の改善をふりかえりに組み込む
試験で問われるポイント
- 「ソースからデプロイまでを自動化したい」→ CodePipeline(オーケストレーター)
- パイプラインは「ステージ」で区切られ、各ステージに「アクション」が入る
- 本番前の人の確認には「手動承認アクション」を使う
- 実体のビルドは CodeBuild、デプロイは CodeDeploy や CloudFormation が担う
- ソース変更の検知はポーリングよりイベント駆動が推奨
関連サービス・比較
ビルドの実体を担う CodeBuild とよく混同されます。役割の違いを押さえましょう。
| 観点 | CodePipeline | CodeBuild |
|---|---|---|
| 役割 | 工程全体のオーケストレーション | ビルドやテストの実行 |
| 処理範囲 | ソースからデプロイまでを連結 | 1つのビルド単位を処理 |
| 単体での使い方 | 他サービスを束ねて使う | ビルドジョブとして単独でも使える |
| 課金の考え方 | アクティブなパイプライン数 | ビルドの実行時間 |
ハンズオン / CLI例
# JSON 定義からパイプラインを作成
aws codepipeline create-pipeline \
--cli-input-json file://pipeline.json
# パイプラインを手動で起動(最新のソースで実行を開始)
aws codepipeline start-pipeline-execution \
--name my-app-pipeline
# 現在の状態とステージごとの成否を確認
aws codepipeline get-pipeline-state \
--name my-app-pipeline
AWS Service
AWS CodePipelineを実務で読む
TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。
解決すること
開発者ツール
比較で見る軸
クラウド: AWS / カテゴリ: 開発者ツール / 難易度: basic
導入後に効く点
ステージとアクションを組み合わせ、手動承認や並列処理も柔軟に構成できる。
先に潰すリスク
サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。
- クラウド
- AWS
- カテゴリ
- 開発者ツール
- 難易度
- basic
- 関連資格
- DOP-C02 / DVA-C02
- 設計柱
- operational
判断チェックリスト
- 自社の用途が「開発者ツール / operational」に近いか確認する。
- 強みである「コードの変更を起点に、ビルド・テスト・デプロイを段階的に自動実行する。」が本当に評価軸になるか確認する。
- 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
- 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
- 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
- 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。