デプロイ前に毎回チェックすること

金曜の午後に本番を壊したことがあります。ステージングでは問題なさそうだった設定変更をプッシュしたんですが、1つの環境変数が開発用のデータベースURLを参照していました。

サイト全体が40分ダウン。金曜日。午後4時。スマホが鳴り止みませんでした。

それ以来、チェックリストを作りました。長くないです。でも毎回必ず守ります。例外なし。「CSSをちょっと直しただけ」でも例外なし。

チェックリスト

1. 変更を差分で確認する

デプロイ前に、何が出ていくのか正確に確認します。自分が変えたと思っているものではなく、実際に変わったもの。

git diff main...HEAD

差分を、意図した変更と照合します。予期しないものが差分に含まれていたら、止めて理由を調べます。

これで、うっかり入ったデバッグログ、残ったテストデータ、ステージングに含まれていると気づかなかった環境設定の変更を何度もキャッチしてきました。

2. 設定ファイルをバリデーションする

JSON設定ファイルは壊れやすい。カンマ1つでもないと全部壊れる。エラーメッセージは大抵「Unexpected token」みたいな役に立たないもの。

変更した設定ファイルは全部、デプロイ前にJSONバリデーターに貼り付けます。金曜午後4時に目では見逃す構文エラーをキャッチしてくれます。

3. 環境変数をチェックする

これが僕をやらかした原因です。ステージングと本番は見た目が同じだけど、環境変数は違う。データベースURL、APIキー、フィーチャーフラグ——どれか1つでも間違っていると、追跡が難しいサイレント障害を引き起こします。

環境間で異なる環境変数のチェックリストを用意して、それぞれ確認します。面倒？はい。本番を落とすよりマシ？それもはい。

4. クリティカルパスをテストする

デプロイのたびにフルテストスイートは回しません（それはCIの仕事）。でもクリティカルなユーザーパスは手動でテストします：

• ユーザーはサインアップできるか？
• ログインできるか？
• プロダクトのメイン機能を使えるか？
• お金を払えるか？

これらのどれかが壊れたら、他はすべて無関係です。

5. アセットサイズをチェックする

フロントエンドの変更をリリースする前に、新しいアセットが不合理に大きくないか確認します。未圧縮の画像やミニファイされていないJavaScriptバンドルは、一晩で読み込み時間を台無しにできます。

クイックチェック：

• 200KBを超える画像がないこと（正当な理由がない限り）
• CSSとJSはミニファイ済み
• うっかり新しいフォントが追加されていないこと

6. ロールバックプランを確認する

何かおかしくなった時、このデプロイを素早く元に戻せるか？

ほとんどのプロジェクトでは git revert して再デプロイ。でもデプロイにデータベースマイグレーションが含まれている場合、ロールバックはもっと複雑。インシデント中ではなく、デプロイ前にこれを把握しておく。

リストに入っていないもの

入っていないものに注目：

• 全テスト実行 — CIが処理する。CIでテストがパスしたら、信頼する。
• コードレビュー — マージ前に済んでいる。デプロイ時のアクティビティではない。
• ドキュメント更新 — 重要だけど、デプロイのブロッカーではない。

デプロイチェックリストは「これは本番を壊すか？」に特化しています。コード品質、ドキュメント、プロセスについてではない。それらも重要ですが、もっと前の段階で行うもの。

金曜ルール

金曜の午後にはもうデプロイしません。何かが壊れたら、丸一日の営業日を使って直したい。不安な週末は過ごしたくない。

月曜から木曜、営業時間中。それが僕のデプロイウィンドウ。例外はあるけど、まれで意図的なものだけ。

---

チェックリストはワクワクしません。デプロイチェックリストについてブログを書いて有名になる人はいません。でもチェックリストの目的は面白いことではなく、忘れていた1つのことをキャッチすること。1回救ってくれれば、かかる2分の元は取れます。