Rollback 回滾

把正式服務退回上一個穩定版本。

先用一句話理解

把正式服務退回上一個穩定版本。

打個比方

像新菜單出問題，先換回舊菜單繼續營業。

什麼時候會遇到

上線後出現嚴重錯誤、付款失敗、資料異常時。

再往深一點看

Rollback 是當新版本 deploy 到 production 後發現嚴重問題，把流量切回上一個已知穩定版本的應急操作。它解決的核心問題是「新版本出問題時不用慌亂修 bug 再 deploy，而是先讓服務回到可用狀態」。Vercel 和 Netlify 都保留每一次的 deployment 快照，一鍵就能切換；但 rollback 有一個常被忽略的複雜度：如果新版本同時跑了資料庫 migration（加欄位、改資料結構），回滾程式碼後舊程式碼可能不相容新的資料庫 schema，這時 rollback 反而會造成新問題。因此，可以安全 rollback 的 deployment 必須確保資料庫變更是「向後相容」的。

舉個例子

你 deploy 了新版結帳流程，Sentry 馬上報出 checkout API 大量 500 錯誤，你在 Vercel 的 Deployments 列表找到上一個 deployment，點 Promote to Production，兩分鐘後舊版本回來，錯誤停止，再慢慢去查新版程式碼哪裡有問題。

常見誤解

- 沒有在 Vercel 或 Netlify 保留 deployment 歷史，或用了沒有版本管理的 hosting，出問題才發現根本無從回滾，只能硬著頭皮在 production 緊急 debug。
- 做了破壞性的資料庫 migration（刪欄位、改欄位型別）後才 rollback 程式碼，舊版程式碼找不到已刪除的欄位，回滾後錯誤反而更多。
- 事前沒演練過 rollback 流程，真正出問題時第一次找 rollback 按鈕在哪、流程是什麼，在緊張中多浪費了十幾分鐘。