隕石という名の
リリース
「機能が全部揃ってからリリースしたい」。
その願いは、半年の開発期間と、一晩の悪夢を生み出しました。
3ヶ月分の変更を一度に投入するのは、運用環境に巨大な隕石を落とすのと同じです。
爆発の衝撃で、ユーザーもデータも吹き飛びます。
- リリース間隔が3ヶ月以上空いている
- リリース作業には、開発チーム全員の待機が必要だ
- 「コードフリーズ」期間が2週間以上ある
- リリース当日、神に祈ったことがある
変更量が多ければ多いほど、失敗率は指数関数的に跳ね上がります。
01. 恐怖のビッグバン
大規模なリリース（ビッグバン）が失敗する理由は単純です。
「何が原因で壊れたか」が特定できないからです。
100箇所の変更が含まれたリリースでエラーが出ても、どの1行が犯人か分かりません。
結果、深夜までデバッグし、最後は泣きながら「切り戻し（ロールバック）」することになります。
そうすれば、
すぐに直せる。
02. 継続的デリバリー（CD）への道
リリースを「イベント」にしてはいけません。
リリースは「日常業務」であるべきです。
AmazonやGoogleは1日に何千回もデプロイしています。
彼らは魔法を使っているわけではありません。
「変更を極限まで小さくして、自動テストを通し、すぐに出す」ことを徹底しているだけです。
03. フィーチャートグルの活用
「作りかけの機能は出せない」？
いいえ、出せます。
「フィーチャートグル（機能フラグ）」を使えば、コードは本番環境にあっても、
設定でOFFにしておけばユーザーには見えません。
これにより、開発とリリースのタイミングを分離し、巨大なマージコンフリクトを防ぐことができます。