每次部署前我都會檢查的事

我有一次在禮拜五下午搞壞了線上環境。推了一個設定檔變更，在 staging 看起來沒問題，但有一個環境變數參照到了 dev 的資料庫 URL。

整個網站掛了 40 分鐘。在禮拜五。下午四點。我的手機響個不停。

從那之後，我有了一份清單。不長。但每一次我都照做。沒有例外。就算是「只是改一點 CSS」也一樣。

清單

1. Diff 一下變更

部署前，我會看到底有什麼東西要出去。不是我以為改了什麼——而是實際改了什麼。

git diff main...HEAD

我會把 diff 跟我原本打算修改的東西做比對。如果 diff 裡有我沒預期到的東西，我就停下來搞清楚原因。

這個方法幫我抓過不小心留下的 debug log、忘記清掉的測試資料，還有我不知道被 stage 進去的環境設定變更。

2. 驗證設定檔

JSON 設定檔很脆弱。少一個逗號就全部壞掉，而且錯誤訊息通常只會說類似 Unexpected token 這種沒什麼幫助的東西。

我在部署前會把每一個修改過的設定檔貼到 JSON 驗證器 裡。能抓到你在禮拜五下午四點用肉眼看不到的語法錯誤。

3. 檢查環境變數

這就是害到我的那個。Staging 和 production 看起來一樣，但環境變數不同。資料庫 URL、API key、feature flag——任何一個錯了都可能造成很難追蹤的無聲失敗。

我有一份環境之間不同的環境變數清單，每次都逐一確認。很煩嗎？是的。比搞壞線上環境好嗎？也是的。

4. 測試關鍵路徑

我不會在每次部署前跑完整的測試套件（那是 CI 的事）。但我會手動測試關鍵的使用者路徑：

• 使用者可以註冊嗎？
• 可以登入嗎？
• 可以做我們產品的主要功能嗎？
• 可以付款嗎？

如果這些任何一個壞了，其他都無所謂。

5. 檢查素材大小

在推前端變更之前，我會檢查有沒有新素材大得不合理。一張沒壓縮的圖片或沒壓縮的 JavaScript bundle 可能一夜之間拖垮你的載入時間。

快速檢查：

• 沒有超過 200KB 的圖片（除非有充分理由）
• CSS 和 JS 有壓縮過
• 沒有不小心加進去的新字型

6. 確認回滾計畫

如果出了問題，我能快速復原這次部署嗎？

大多數專案就是 git revert 然後重新部署。但如果部署包含資料庫遷移，回滾就複雜多了。在你部署之前就搞清楚這些，不是在事故發生時。

我的清單上沒有的東西

注意什麼沒列在上面：

• 跑所有測試——CI 處理這個。如果測試在 CI 通過了，我就信任它們。
• Code review——在 merge 之前就已經做了。不是部署時要做的事。
• 更新文件——重要，但不是部署的阻擋項。

部署清單專門針對「這會不會搞壞線上環境？」不是關於程式碼品質、文件或流程。那些也很重要，但它們在更早的階段處理。

禮拜五法則

我不再在禮拜五下午部署了。如果出事了，我希望有一個完整的工作日來修，而不是一個充滿焦慮的週末。

禮拜一到禮拜四，上班時間。那就是我的部署窗口。例外是有的，但很少而且是刻意為之。

---

一份清單並不刺激。沒有人寫部署清單的部落格文章還因此爆紅。但清單的目的不是為了有趣——而是為了抓住你忘掉的那一件事。而它只要救你一次，就值得你每次花的那兩分鐘。