5-4 CI/CDパイプライン
Continuous Integration / Continuous Delivery
1. CI/CDとは
1.1 継続的インテグレーション（CI）
CI（Continuous Integration）は、開発者がコードを頻繁にメインブランチに 統合し、その都度自動でビルドとテストを実行するプラクティスである。
| CIの目的 | 効果 |
|---|---|
| 早期の問題発見 | コミット直後にビルドエラー・テスト失敗を検知 |
| 統合リスクの軽減 | 小さな変更を頻繁に統合し、大規模マージを回避 |
| 品質の可視化 | テストカバレッジ、静的解析結果を継続的に確認 |
| 開発速度の向上 | 手動作業の削減、フィードバックの高速化 |
1.2 継続的デリバリー/デプロイメント（CD）
CDにはデリバリーとデプロイメントの2つの概念がある。
| 概念 | 定義 | 本番デプロイ |
|---|---|---|
| 継続的デリバリー | いつでもリリース可能な状態を維持 | 手動承認後 |
| 継続的デプロイメント | すべての変更を自動で本番にデプロイ | 自動 |
継続的デリバリーでは本番デプロイ前に人間の承認が入る。 継続的デプロイメントは完全自動化だが、高度なテスト自動化と モニタリングが前提となる。多くの組織では継続的デリバリーから始める。
2. パイプラインの構成
2.1 基本的なパイプライン
CI/CDパイプラインは複数のステージで構成される。
| ステージ | 内容 | 実行タイミング |
|---|---|---|
| Source | コードの取得（checkout） | トリガー時 |
| Build | コンパイル、依存関係解決 | コード取得後 |
| Test | 単体テスト、結合テスト | ビルド成功後 |
| Analysis | 静的解析、セキュリティスキャン | テスト並行または後 |
| Package | 成果物の作成（Docker imageなど） | 品質チェック通過後 |
| Deploy | 環境へのデプロイ | パッケージ作成後 |
2.2 パイプラインのトリガー
パイプラインは様々なイベントをトリガーとして実行される。
| トリガー | 用途 |
|---|---|
| プッシュ | コードがプッシュされたら実行 |
| プルリクエスト | PR作成・更新時に実行 |
| マージ | メインブランチへのマージ時 |
| スケジュール | 定期実行（夜間ビルドなど） |
| 手動 | ボタンクリックで実行 |
3. CI/CDツール
3.1 主要なCI/CDサービス
複数のCI/CDサービスがあり、プロジェクトに合わせて選択する。
| サービス | 特徴 | 設定ファイル |
|---|---|---|
| GitHub Actions | GitHubと統合、マーケットプレイス | .github/workflows/*.yml |
| GitLab CI/CD | GitLabと統合、Auto DevOps | .gitlab-ci.yml |
| Jenkins | オープンソース、プラグイン豊富 | Jenkinsfile |
| CircleCI | 高速、Docker対応 | .circleci/config.yml |
| AWS CodePipeline | AWS統合 | 設定ファイル + GUI |
3.2 パイプライン設定の例（GitHub Actions）
基本的なワークフロー構造
name: ワークフロー名
on: トリガー条件（push、pull_requestなど）
jobs: ジョブの定義
build: ジョブ名
runs-on: 実行環境
steps: 実行ステップ
4. デプロイ戦略
4.1 デプロイ方式
デプロイ方式にはリスクレベルの異なる複数のアプローチがある。
| 方式 | 説明 | リスク |
|---|---|---|
| ビッグバンデプロイ | 一度に全サーバーを更新 | 高（障害時の影響大） |
| ローリングデプロイ | 段階的にサーバーを更新 | 中 |
| ブルー/グリーンデプロイ | 新旧環境を切り替え | 低（即座にロールバック可能） |
| カナリアリリース | 一部のユーザーにのみ新版を提供 | 最低 |
4.2 ブルー/グリーンデプロイ
本番環境（ブルー）とは別に、新版の環境（グリーン）を用意し、 ロードバランサーで切り替える方式。問題発生時は即座に旧環境に戻せる。
4.3 カナリアリリース
新版を一部のユーザー（例：5%）にのみ提供し、 問題がなければ段階的に拡大する方式。 本番環境で新版の挙動を検証できる。
どのデプロイ方式を採用する場合も、問題発生時のロールバック手順を 事前に準備しておくことが重要である。 ロールバックのテストも定期的に実施すべきである。
5. ベストプラクティス
5.1 パイプラインの原則
効果的なパイプラインを構築するための原則がある。
| 原則 | 説明 |
|---|---|
| 高速フィードバック | 失敗は早く検知（10分以内が理想） |
| 再現可能 | 同じ入力に対して同じ結果 |
| 自己テスト | パイプライン自体もテスト対象 |
| 可視化 | 状態をダッシュボードで確認可能 |
| 失敗の即座修正 | ビルド失敗は最優先で対応 |
5.2 セキュリティ
CI/CDパイプラインのセキュリティ対策も重要である。
| 対策 | 内容 |
|---|---|
| シークレット管理 | APIキー等は環境変数やSecret Managerで管理 |
| 依存関係スキャン | 脆弱性のあるライブラリを検知 |
| SAST/DAST | 静的・動的セキュリティテスト |
| 最小権限 | パイプラインに必要最小限の権限のみ付与 |
パイプラインの設定もコードとしてバージョン管理する。 設定変更の履歴が残り、レビューも可能になる。
開発・実装の基本を学習しました。 次は「第6章 テスト」で、ソフトウェアテストについて学習しよう。
[1] Humble, J. (2010). Continuous Delivery.
[2] Fowler, M. (2006). Continuous Integration.