フレームワーク活用ガイドひとことで言うと#
コードの変更を頻繁に統合し、ビルド・テスト・デプロイを自動化するプラクティス。CI（継続的インテグレーション）で品質を保ち、CD（継続的デリバリー/デプロイ）でリリースを高速化する。
押さえておきたい用語#
- パイプライン（Pipeline）
- ビルド・テスト・デプロイなどの処理を順序立てて自動実行する一連のステージのこと。コードのプッシュをトリガーに起動し、各ステージが順次またはパラレルに実行される。
- Four Keys
- デプロイ頻度・リードタイム・変更失敗率・復旧時間の4つの指標のこと。DORA（DevOps Research and Assessment）が提唱し、チームのデリバリーパフォーマンスを測定する業界標準。
- Flaky Test（不安定なテスト）
- 同じコードに対して実行するたびに結果が変わる不安定なテストのこと。CI全体の信頼性を損ない、開発者がテスト結果を無視する原因となる。
- カナリアリリース（Canary Release）
- 新バージョンをまず一部のトラフィック（例: 5%）にだけ公開し、問題がなければ段階的に全体へ展開するデプロイ手法を指す。
CI/CDの全体像#
こんな悩みに効く#
- 手動デプロイに半日かかり、リリースが怖いイベントになっている
- マージしたらテストが壊れていて、誰がいつ壊したかわからない
- リリース頻度が低く、1回のリリースに大量の変更が含まれてしまう
基本の使い方#
コードをプッシュするたびに、自動でビルドとテストが走る環境を作る。
- GitHub Actions、GitLab CI、CircleCI などのCIサービスを導入する
- ビルド → ユニットテスト → リンター → 静的解析の順にパイプラインを組む
- PRのマージ条件にCIの成功を必須にする
ポイント: CIが10分以上かかると開発者が待てなくなる。高速化を常に意識する。
CIの品質はテストの品質で決まる。
- ユニットテスト: 高速で大量に。カバレッジ80%以上を目標に
- インテグレーションテスト: DB、API連携の確認
- E2Eテスト: 主要なユーザーフローだけを対象にする
ポイント: テストピラミッド（ユニット多め、E2E少なめ）を意識する。
CIが通ったコードを、自動でステージング・本番にデプロイする。
- ステージング環境への自動デプロイ（Continuous Delivery）
- 本番環境への自動デプロイ（Continuous Deployment）
- ブルーグリーンデプロイ、カナリアリリースでリスクを低減する
ポイント: Continuous Delivery（手動承認あり）とContinuous Deployment（完全自動）は別物。まずはDeliveryから。
デプロイ後の状態を監視し、問題があれば即座にロールバックする。
- デプロイ後のエラーレート、レスポンスタイムを監視
- 異常を検知したら自動でロールバックする仕組み
- デプロイ頻度、リードタイム、変更失敗率をメトリクスとして追跡
ポイント: Four Keys（デプロイ頻度、リードタイム、変更失敗率、復旧時間）で改善度を測る。
具体例#
パイプライン構成:
- トリガー: PRの作成・更新時、mainブランチへのマージ時
- ビルド:
npm install→npm run build（3分） - テスト: ユニットテスト（2分）→ インテグレーションテスト（5分）
- 静的解析: ESLint + TypeScript型チェック（1分）
- ステージングデプロイ: mainマージ時にステージング環境へ自動デプロイ
- 本番デプロイ: ステージングで動作確認後、承認ボタンで本番へデプロイ
- モニタリング: デプロイ後15分間、エラーレートを監視。閾値超えで自動ロールバック
結果: PRからマージまで平均30分、本番デプロイまで1時間。以前は手動で半日かかっていたのが92%短縮。
Before: テストスイート800件中、Flaky Testが23件。CIの成功率は72%。開発者は「また落ちた」でCIを無視し、mainブランチが週に3回壊れていた。
対策:
- Flaky Testを特定するダッシュボードを構築（過去30日の成功率が95%未満のテストを自動検出）
- 発見した23件を専用の隔離スイートに移動し、メインCIからは除外
- 毎スプリントで2〜3件ずつ根本原因を修正して本スイートに復帰
After（3ヶ月後）: Flaky Testが23件→2件。CIの成功率が72%→97%。mainブランチが壊れる頻度が週3回→月1回に改善。開発者がCIの結果を信頼して行動する文化が復活した。
Before: 10人チーム。月1回の手動リリース。1回のリリースに平均47件の変更が含まれ、リリース後のバグ発生率は30%。
CI/CD導入ステップ:
- 月1〜2: GitHub ActionsでCIを構築。ユニットテスト300件を自動実行
- 月3: ステージング自動デプロイを導入。PRマージ→5分でステージングに反映
- 月4: カナリアリリースを導入。本番トラフィックの5%→25%→100%と段階的に展開
After（6ヶ月後）:
- リリース頻度: 月1回→週3回
- 1回あたりの変更数: 47件→5件
- リリース後バグ発生率: 30%→5%
- 小さくリリースすることでリスクが劇的に低下した
やりがちな失敗パターン#
- CIが遅すぎて無視される — ビルド+テストに30分以上かかると、開発者はCIの結果を待たずにマージしてしまう。CIは10分以内に収める。並列実行やキャッシュを活用する
- テストが不安定（Flaky）で信頼されない — ランダムに失敗するテストがあると、「また失敗か」でCIの結果が無視される。不安定なテストは即修正するか、隔離する
- CDを入れたがロールバック手順がない — 自動デプロイしたが、問題発生時に戻し方がわからずパニック。ロールバック手順を必ず整備し、定期的に訓練する
- CIの成功をマージ条件にしていない — CIが存在するのにマージ時に必須にしていないため、テスト失敗のままマージされる。Branch Protection Ruleで必須化する
まとめ#
CI/CDは現代のソフトウェア開発の基盤。CIで品質を担保し、CDでリリースを高速化する。導入のポイントは「テストの品質」と 「パイプラインの速度」。まずはCIから始めて、自動テストを充実させ、段階的にCDへ進化させよう。