CI/CD — 壊れていることに、人間より先に気づく

What — パイプラインの各段階

デプロイ戦略

[旧][旧][旧][旧]
[新][旧][旧][旧]   ← 1台ずつ
[新][新][旧][旧]
[新][新][新][新]

切り戻し: 逆順に入れ替える（時間がかかる）

Why — CI/CD が本当に買っているもの

自動化は手段です。目的は2つあります。

目的1：壊れた変更が本番に届かないこと

人間のレビューだけでは、すべての破壊を検出できません。型の不整合、テストの失敗、依存関係の壊れ。これらは機械のほうが確実に見つけます。

目的2：いつでも戻せること

どれだけ検証しても、本番でしか起きない問題があります。そのとき重要なのは「問題を起こさないこと」ではなく、**「起きたときに素早く戻せること」**です。

戻すのに30分かかるなら、障害は30分続きます。3秒で戻せるなら3秒です。この差が、リリースの心理的な重さを決めます。

同じ成果物を使い回す

環境ごとにビルドすると、「検証では動いたのに本番で動かない」が起きます。

❌ 環境ごとにビルド
  検証用にビルド → 依存ライブラリのマイナーバージョンが 1.2.3
  本番用にビルド → その間に 1.2.4 が出ていて、そちらが入る

✅ 一度だけビルドして使い回す
  ビルド → artifact:sha-a3f9c2
  検証環境にデプロイ → artifact:sha-a3f9c2
  本番環境にデプロイ → artifact:sha-a3f9c2  （同じもの）

検証したものと、本番に出すものが同一であることが保証されます。 環境ごとの差分は、成果物の中ではなく環境変数で表現します。

DB マイグレーションが一番の難所

コードは戻せますが、実行済みのマイグレーションは簡単には戻せません。

❌ 危険な手順
  1. カラムを削除するマイグレーションを実行
  2. 新コードをデプロイ
  → 問題が起きて旧コードに戻したいが、カラムが無いので動かない

✅ 安全な手順（拡張 → 移行 → 縮小）
  1. 新しいカラムを追加する（旧コードは無視するので影響なし）
  2. 新旧どちらでも動くコードをデプロイ
  3. データを移行する
  4. 旧カラムを使わないコードをデプロイ
  5. 落ち着いてから旧カラムを削除する

各段階で、前後のバージョンが同時に動いても壊れないようにします。ローリングデプロイでは新旧が必ず混在するため、これは必須の考え方です。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。