AWS CodePipeline

解決する課題

手作業のリリースは、ビルド忘れ・テスト漏れ・デプロイ手順のばらつきといったヒューマンエラーの温床です。CodePipeline はこの一連の流れを自動化します。

• コードの変更を起点（トリガー）に、ビルドからデプロイまでを自動で連鎖実行する
• 手順をパイプライン定義としてコード化・標準化し、誰が実行しても同じ結果になる
• 失敗したステージで自動停止し、問題のある変更が本番へ流れるのを防ぐ

主要概念と用語

• パイプライン: ソースからデプロイまでの一連のワークフロー全体を表す単位
• ステージ: パイプラインを区切る論理的なフェーズ（例: ソース、ビルド、デプロイ）
• アクション: ステージ内で実行される個々の作業（ビルド実行、テスト、承認など）
• アーティファクト: ステージ間で受け渡されるファイル群。多くは S3 バケットに格納される
• トランジション: ステージからステージへ成果物が進む経路。有効化・無効化で流れを制御できる
• プロバイダー: 各アクションを実際に処理するサービス（ソースは CodeCommit や GitHub、ビルドは CodeBuild など）

仕様・制限・クォータ

• パイプラインは複数のステージで構成し、各ステージには1つ以上のアクションを置く
• アクションは直列にも並列にも配置でき、並列アクションはすべて完了するまで次へ進まない
• ステージ間で受け渡すアーティファクトは S3 バケットに保存され、後続アクションが入力として利用する
• V1 は標準的な定義、V2 はトリガー・変数と QUEUED / PARALLEL 実行を追加する。種類を省略すると V1 になる
• 実行モードは最新実行を優先する SUPERSEDED、到着順の QUEUED、独立して走る PARALLEL。PARALLEL ではステージのロールバックを利用できない
• 1 パイプラインは 2〜50 ステージ、最大 1,000 アクション。QUEUED / PARALLEL は 1 パイプライン最大 50 同時実行である
• アクション種別はソース、ビルド、テスト、デプロイ、承認、呼び出し（Lambda 等）に大別される

内部の仕組み

横にスクロール

CodePipeline は自身が処理を行うのではなく、各アクションを外部のプロバイダーに委譲するオーケストレーターです。各アクションの結果（成功・失敗）を受け取り、次のステージへ進めるかどうかを判断します。

• ソースステージで変更を検知すると、対象をアーティファクトとして S3 に格納し、後続へ渡す
• ビルドやデプロイのアクションは CodeBuild・CodeDeploy・CloudFormation などのプロバイダーが実体を処理する
• 変更検知は、定期的なポーリングよりも EventBridge やリポジトリ側の通知によるイベント駆動が推奨される

設計パターン / ベストプラクティス

• 段階的デプロイ: 開発→ステージング→本番のように環境ごとにステージを分け、各段で検証を挟む
• 手動承認ゲート: 本番デプロイの前に承認アクションを置き、人の確認を必須にする
• パイプライン自体をコード化: 定義を CloudFormation や CDK で管理し、再現性とレビュー可能性を確保する
• 並列アクションで時間短縮: 独立したテストやビルドは並列に並べ、全体のリードタイムを縮める

運用・監視

• 実行履歴: パイプラインの各実行がどのステージで成功・失敗したかをコンソールや API で追跡できる
• 通知: ステージの失敗や承認待ちを EventBridge 経由で検知し、SNS や Chatbot 経由でチームへ知らせる
• 失敗時の切り分け: 失敗したアクションのプロバイダー側ログ（CodeBuild のビルドログ等）を確認する
• 再実行: 失敗したステージから、あるいはパイプライン全体を再実行できる

コスト

V1 は作成から 30 日を超え、その月に変更を処理したアクティブパイプライン 1 本あたり月 1 USDです。V2 は手動承認とカスタムアクションを除くアクション実行時間を分単位で切り上げ、1 分 0.002 USDです。無料枠は V1 が月 1 本、V2 がアカウント合計月 100 分です。

• V1 は変更が流れない月は課金されない。V2 は不要な起動と長時間アクションを減らす
• 全体コストはパイプライン本体よりも、ビルド時間やデプロイ先リソースの比重が大きくなりやすい

セキュリティ

• サービスロール: CodePipeline には IAM のサービスロールをアタッチし、必要な権限のみを最小権限で付与する
• アーティファクト保護: ステージ間の成果物が入る S3 バケットは暗号化し、KMS で鍵を管理する
• 承認の統制: 本番への承認アクションを実行できる権限を絞り、誰でも承認できない状態にする
• クレデンシャル排除: パイプライン内でアクセスキーをハードコードせず、ロールで権限を渡す

Well-Architected の観点

• 運用上の優秀性: リリース手順をコード化・自動化し、手作業によるばらつきとミスを排除する。失敗を早期に検知し、再実行で迅速に回復できる
• 変更を小さく頻繁にデプロイする文化を支え、パイプライン定義の改善をふりかえりに組み込む

試験で問われるポイント

関連サービス・比較

ビルドの実体を担う CodeBuild とよく混同されます。役割の違いを押さえましょう。

ハンズオン / 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