LESSON 20分

CI/CDのベストプラクティス

ストーリー

「ツールを導入するだけではCI/CDは成功しない。 大切なのは、チーム全体の習慣を変えることだ」

木村先輩が、過去のプロジェクトの失敗談を話し始めた。

「以前のチームでは、Jenkinsを導入したのにうまくいかなかった。 理由は簡単だ。ビルドが壊れても誰も直さなかった。 テストが遅くなっても誰も気にしなかった。 ツールはただのツールでしかない」

「では、何が一番大事なんですか？」

「チームの文化だ。自動化を信頼し、壊れたものはすぐ直す。 その文化がないと、どんなツールを入れても宝の持ち腐れだ」

パイプライン設計のベストプラクティス

1. 高速なフィードバック

CIパイプラインは10分以内を目標にしましょう。

推奨：フェイルファスト戦略

[push]
  │
  ├─ Stage 1 (1分) : Lint + 型チェック  ← 最も速いチェックを最初に
  │   失敗 → 即通知（コード修正を指示）
  │
  ├─ Stage 2 (3分) : 単体テスト
  │   失敗 → 即通知（テスト修正を指示）
  │
  ├─ Stage 3 (5分) : 結合テスト + ビルド
  │   失敗 → 即通知
  │
  └─ Stage 4 (並列) : E2E + セキュリティスキャン
      結果 → まとめて通知

合計: 約10分以内

2. パイプラインをコードとして管理

パイプラインの定義もバージョン管理の対象です。

やることやらないこと
YAMLファイルをGitで管理GUIだけで設定する
PRでパイプライン変更をレビュー直接本番のパイプラインを編集
環境ごとの差分を最小化環境ごとに全く別のパイプラインを作る

3. テストピラミッドを意識する

テストピラミッド

         /\
        /  \        E2Eテスト
       / E2E\       少数・遅い・高コスト
      /------\
     /  結合   \    結合テスト
    /  テスト   \   中程度の数
   /------------\
  /   単体テスト   \  単体テスト
 /                \  多数・速い・低コスト
/------------------\

CIで実行するテスト配分:
- 単体テスト: 70%（高速、毎pushで実行）
- 結合テスト: 20%（中速、PRマージ時に実行）
- E2Eテスト: 10%（低速、デプロイ前に実行）

ブランチ戦略とCI/CD

トランクベース開発

CI/CDと最も相性が良いブランチ戦略です。

トランクベース開発

main ─────●─────●─────●─────●─────●─────→
           \   / \   /       \   /
feature/a  ●──●   │         │
                  feature/b  ●──●
                              feature/c

特徴:
- 短命なフィーチャーブランチ（1〜2日以内）
- mainに頻繁にマージ
- 全てのマージでCIが走る

GitHub Flow

GitHub Actionsとの組み合わせで広く使われています。

GitHub Flow + CI/CD

main ──────────●──────────●──────────→
                \        /
feature/login    ●──●──●
                 │  │  │
                 CI CI CI  ← 毎pushでCI実行
                       │
                    PR作成 → レビュー → マージ → CD

セキュリティのベストプラクティス

シークレット管理

やることやらないこと
専用のシークレットストアを使うコードにAPIキーをハードコード
環境変数で注入するログにシークレットを出力
定期的にローテーションする全環境で同じシークレットを使う
最小権限の原則を適用する管理者権限のトークンを共有

サプライチェーンセキュリティ

サプライチェーンリスク

[自分のコード] → [依存パッケージ] → [CI/CDツール] → [デプロイ先]
                      │                   │
                 脆弱性の混入          アクション乗っ取り
                 バージョン固定で対策    SHA固定で対策
対策説明
依存パッケージのバージョン固定package-lock.json を必ずコミット
アクションのSHA固定uses: actions/checkout@v4 より @sha256:...
依存関係の自動更新Dependabot / Renovateで脆弱性を検知
最小権限のGITHUB_TOKENpermissions を明示的に指定

チーム文化のベストプラクティス

ビルドが壊れたら最優先で直す

ビルド壊れた時のフロー

  [ビルド失敗通知]
       │
       ▼
  誰がコミットした？
       │
       ├── 自分 → 即座に修正開始
       │
       └── 他の人 → 声をかけて支援
                     （放置しない）

ルール:
- ビルドが壊れている間は新しいマージをしない
- 15分で直せないなら revert する
- ビルド状態はチームの共有責任

メトリクスを可視化する

メトリクス目標値可視化方法
CIパイプライン実行時間10分以内ダッシュボード
ビルド成功率95%以上週次レポート
デプロイ頻度1日1回以上カレンダー表示
平均修復時間（MTTR）1時間以内アラート集計
テストカバレッジ80%以上CIレポート

アンチパターンと対策

アンチパターン症状対策
巨大なモノリスCI1回のCIに30分以上ステージ分割、並列化
テスト不安定（Flaky）ランダムに失敗根本原因を特定し修正
手動ステップの残存「このステップだけ手動で」全て自動化する
ブランチの長寿命化数週間マージされないPR小さなPRに分割
シークレットの平文管理.env ファイルをコミットシークレットストア使用

まとめ

ポイント内容
高速フィードバックCIは10分以内、フェイルファスト戦略
テストピラミッド単体70%、結合20%、E2E 10%の配分
セキュリティシークレット管理とサプライチェーン保護
チーム文化ビルド修復最優先、メトリクス可視化

チェックリスト

  • フェイルファスト戦略を説明できる
  • テストピラミッドの概念を理解した
  • シークレット管理のベストプラクティスを把握した
  • CI/CDにおけるチーム文化の重要性を理解した

次のステップへ

Step 1の内容を理解度チェッククイズで確認しましょう。 CI/CDの基本概念が固まったら、いよいよStep 2でGitHub Actionsの実践に入ります。

推定読了時間: 20分