CI/CD Pipeline Architecture

1. CI/CDはリリースプロセス全体を設計する

ソフトウェア変更には、送信元、ビルド、テスト、リリース判断、デプロイという複数の責任があります。

送信元
↓
統合
↓
ビルド
↓
テスト
↓
リリース判断
↓
デプロイ

これらを個別の手作業でつなぐと、手順差、テスト漏れ、アーティファクトの取り違え、本番承認の曖昧さが生じやすくなります。CI/CDパイプラインではリリースプロセスを標準化し、要件に応じて自動化と制御を配置します。

2. 継続的統合：変更を小さく統合して早期検証する

継続的統合（CI：継続的インテグレーション）は、コード変更を継続的に共有 リポジトリへ統合し、自動ビルドやテストで問題を早期検出するプラクティスです。

開発者 A ─┐
開発者 B ─┼─→ 共有 リポジトリ
開発者 C ─┘
                    │
                    ▼
              自動化されたビルド
                    │
                    ▼
              自動化されたテスト
                    │
             ┌──────┴──────┐
             ▼             ▼
           通過失敗
             │             │
             ▼             └─→ 早期修正
      リリースプロセスへ

CIの決定要因は、頻繁なコード変更 + 自動ビルド + 自動テスト + 早いフィードバックです。本番へ自動デプロイすること自体がCIではありません。

3. 継続的受け渡し：本番昇格前に手動承認を置くリリースフロー

継続的受け渡し（継続的デリバリー）は、CIをさらに進め、ビルド、テスト、ステージングへのデプロイ、検証などを自動化し、変更を本番へリリース可能な状態まで継続的に準備します。

コミット
↓
ビルド
↓
自動化されたテスト
↓
ステージング
↓
検証
↓
リリース 準備完了
↓
手動 承認
↓
本番

この教材ではAWSのCI/CD整理に合わせ、継続的受け渡しでは本番への昇格前に手動承認を置くものとして判断します。

4. 継続的受け渡しと継続的デプロイを混同しない

「すべての変更を自動テストするが本番リリースには変更マネージャーの承認が必要」なら継続的受け渡しです。「自動化されたテストを通過した変更を人の承認なしで本番まで展開する」なら継続的デプロイです。

5. AWS CodePipeline：リリースプロセスをオーケストレーションする

AWS CodePipelineは、ソフトウェア変更がリリースプロセスをどのように通過するかを定義するワークフローサービスです。

パイプライン
├─ ステージ
│   ├─ アクション
│   └─ アクション
├─ ステージ
│   └─ アクション
└─ ステージ
    └─ アクション

例えば送信元、ビルド、テスト、承認、本番デプロイというステージを構成できます。CodePipeline自身がソースコードをコンパイルしたり、アプリケーションをEC2へ直接インストールしたりするのではなく、いつ・どの順番で・どのアクション提供側を実行するかをオーケストレーションします。

6. パイプラインステージとアクションを分ける

パイプラインは複数のステージから構成され、ステージの中に1つ以上のアクションを配置します。

パイプライン
│
├─ ビルドステージ
│   ├─ コンパイル アクション
│   └─ 単位テストアクション
│
└─ デプロイステージ
    └─ デプロイアクション

ステージは環境境界や制御境界として利用できます。同じステージ内のアクションは設定によって直列または並列に実行できるため、1 ステージ = 必ず1 アクションではありません。

7. ステージを環境 / 制御境界として設計する

ステージを単にサービス名で分けるのではなく、どの時点で何が成功している必要があるかで設計します。

ビルド
↓
テスト
↓
ステージング
↓
手動 承認
↓
本番デプロイ

本番変更に変更マネージャーの承認が必要なら、自動化されたテスト成功だけで本番へ進めず、承認ゲートを置いて技術検証とビジネス / 変更承認を分離します。

8. AWS CodeBuild：入力アーティファクトをビルド / テストする

AWS CodeBuildは完全に マネージドなビルドサービスです。CodePipeline内では前段アクションから入力アーティファクトを受け取り、ビルドやテストを実行して後続アクション向けの出力アーティファクトを生成します。

入力アーティファクト
      │
      ▼
AWS CodeBuild
      │
      ├─ 依存関係準備
      ├─ コンパイル / ビルド
      ├─ 単位テスト
      └─ パッケージ
      │
      ▼
出力アーティファクト

CodeBuildのプライマリ責任は、ビルド + テスト + アーティファクト生成です。パイプライン全体のステージ切り替えや本番へのデプロイを管理するサービスではありません。

9. AWS CodeDeploy：アプリケーション改訂をデプロイする

AWS CodeDeployは、検証済み アプリケーション改訂を対象環境へデプロイするサービスです。

代表的なコンピューティングプラットフォームには、Amazon EC2 / オンプレミス、AWS Lambda、Amazon ECSがあります。

検証済み アプリケーション改訂
↓
AWS CodeDeploy
↓
対象実行時

CodeDeployはソースコードをコンパイルするビルドサービスでも、送信元からデプロイまでのリリースプロセス全体をオーケストレーションするサービスでもありません。

10. CodePipeline / CodeBuild / CodeDeployの責任を分離する

CodePipeline → 流れを作る
CodeBuild    → 作る・試す
CodeDeploy   → 配る

11. アーティファクトをステージ間で受け渡す

パイプラインでは、前段アクションが生成したアーティファクトを後段アクションへ渡せます。

送信元
↓
送信元アーティファクト
↓
CodeBuild
↓
ビルドアーティファクト
↓
検証
↓
デプロイ

ビルドに成功したアプリケーションパッケージを同じ改訂としてテスト、ステージング、本番へ流すことで、「テストしたもの」と「本番へデプロイしたもの」が異なるリスクを減らせます。

12. 手動承認は継続的受け渡しのリリースゲート

本番変更に人承認が必要でも、ビルドやテストまでを自動化できます。

コミット
↓
ビルド
↓
自動化されたテスト
↓
ステージング検証
↓
手動 承認
↓
本番デプロイ

承認は自動化を妨げる場当たり的な手作業ではなく、ビジネス要件として意図的に置くゲートです。例えば本番変更の承認が必須なら、継続的受け渡し + CodePipeline 手動承認が自然な設計です。

13. エンドツーエンドアーキテクチャ

開発者
   │ コミット
   ▼
送信元 リポジトリ
   │
   ▼
┌───────────────────────────┐
│       AWS CodePipeline    │
│                           │
│  送信元ステージ             │
│       │                   │
│       ▼                   │
│  ビルドステージ              │
│       └─ AWS CodeBuild    │
│          ビルド / テスト     │
│          アーティファクト         │
│       │                   │
│       ▼                   │
│  検証ステージ         │
│       │                   │
│       ▼                   │
│  承認ステージ           │
│       │                   │
│       ▼                   │
│  デプロイステージ             │
│       └─ AWS CodeDeploy   │
└───────┼───────────────────┘
        ▼
本番

判断の中心は「パイプラインを使うか」だけではなく、どこまで自動化するか、どこで障害を止めるか、どこで人の判断が必要か、ビルドとデプロイをどこへ委譲するかです。

14. シナリオで判断する

シナリオ A：ビルド障害を早く検出したい

多数開発者
↓
コード変更が頻繁
↓
マージ後すぐにビルド / 単位テスト
↓
障害を早期フィードバック

中心となるプラクティスは継続的統合です。ビルド / テスト実行サービスとしてAWS CodeBuildを利用できます。

シナリオ B：本番リリースには承認が必要

コード変更
↓
ビルド
↓
自動化されたテスト
↓
ステージング
↓
変更管理者の承認
↓
本番

中心となるプラクティスは継続的受け渡しです。AWS CodePipelineの承認アクションをリリースゲートとして利用できます。

シナリオ C：ビルドとデプロイの責任を分離したい

CodePipeline
↓
CodeBuild
ビルド / テスト
↓
CodeDeploy
デプロイ

パイプラインオーケストレーション、ビルド、デプロイを異なる責任として設計します。

15. 障害モード

16. SAP-C02判断フロー

ソフトウェア 変更を継続的にリリースしたい
        ↓
頻繁な統合と自動ビルド / テストが必要？
        ↓ はい
継続的インテグレーション
        ↓
ビルド / テストをマネージドサービスへ？
        ↓
AWS CodeBuild
        ↓
リリースプロセス全体をステージとしてオーケストレーション？
        ↓
AWS CodePipeline
        ↓
本番へリリース可能な状態まで自動準備？
        ↓
継続的受け渡し
        ↓
本番前に人承認
        ↓
手動 承認ゲート
        ↓
アプリケーション改訂を実行時へデプロイ？
        ↓
AWS CodeDeploy等

具体的なトラフィック切り替えやデプロイ方式は、可用性 / リスク要件に応じて別途選択します。

まとめ

• 継続的統合は、変更を頻繁に統合し、自動ビルド / テストで早期フィードバックを得るプラクティスです。
• 継続的受け渡しは、変更をリリース可能な状態まで準備し、本番昇格前に手動承認を置きます。
• 継続的デプロイは、明示的承認なしで本番まで自動化します。
• AWS CodePipelineはリリースワークフローをステージとアクションでオーケストレーションします。
• AWS CodeBuildはビルド・テスト・アーティファクト生成を担当します。
• AWS CodeDeployは検証済み アプリケーション改訂を対象実行時へデプロイします。
• ステージには1つ以上のアクションを配置でき、アクションは直列または並列に構成できます。
• 本番への承認がビジネス要件ならパイプライン内に承認ゲートを置きます。
• 具体的なトラフィック切り替えやデプロイ方式は可用性 / リスク要件から別途判断します。