本工作室一年內累積 100 次 Cloudflare 部署 — 主站、遊戲大廳、Worker、各種子專案。100 次裡有完美的、有狼狽回滾的、有半夜緊急修補的。這篇是這些經驗濃縮的 5 個 takeaway。
1. 部署速度比你想的更影響行為
Cloudflare Pages 部署 30 秒完成 vs 傳統 CI 部署 5 分鐘 — 看起來只差 4.5 分鐘，但實際影響是行為層面：
- 30 秒 = 改完隨手部署，當下測試
- 5 分鐘 = 「等等再部署，先做別的事」 → context switch 成本
- 5 分鐘 = 一天部署 3–5 次
- 30 秒 = 一天部署 15–30 次
部署頻率高 = 每次改動小 = 風險小。這個正向循環讓開發節奏完全不同。
2. 回滾比預防 bug 更重要
傳統思維：在部署前防止 bug。修改→測試→staging→production。
新思維：bug 一定會逃過測試。回滾速度 = 真正的安全網。
Cloudflare Pages 的 rollback 是 1 click 完成。實測：發現 bug 到 production 修復 < 60 秒。傳統 CI/CD 常常需要 10–30 分鐘。
有了快速回滾，「敢於部署」變成 default 而不是例外。
3. 部署命名是技術債
第一次部署完隨便寫 commit message「fix」。第 50 次想找「上次改 hero 動畫的那個版本」時，從 50 個「fix」「update」「tweak」裡找半小時。
學到的命名規範：
feat(hero): add liquid chrome 3D animation fix(blog): broken canonical URL on tech-stack chore(deps): update wrangler 4.83 → 4.87 docs(readme): add deployment guide perf(canvas): use devicePixelRatio for retina
類別 + scope + 敘述。Conventional Commits 格式。將來重新 review 100 個部署也能秒懂哪個是哪個。
4. 自動化「無腦操作」
前 30 個部署我手動跑：
git add -A git commit -m "..." git push origin main npx wrangler pages deploy . --project-name=hao0321-studio \ --branch=main --commit-dirty=true --commit-message="..."
第 31 個我寫了個 alias：
# ~/.bashrc
deploy() {
git add -A
git commit -m "$1"
git push origin main
npx wrangler pages deploy . \
--project-name=hao0321-studio \
--branch=main --commit-dirty=true \
--commit-message="$1"
}
# 用法
deploy "fix(blog): typo in tech-stack post"
從 4 個指令壓到 1 個。100 次部署省下的時間 ≈ 1.5 小時，更重要是降低「再做一次」的心理門檻。
5. 部署的心理動力學
觀察自己 100 次部署的時段分布：
| 時段 | 部署比例 | 性質 |
|---|---|---|
| 09:00–12:00 | 15% | 大改動（謹慎期） |
| 14:00–17:00 | 40% | 多次小改動（生產力高峰） |
| 20:00–23:00 | 30% | 晚上靈感修正 |
| 00:00–06:00 | 10% | 緊急 bug fix（壞時段） |
| 06:00–09:00 | 5% | 早起補上昨晚未完 |
學到：
- 下午 2–5 點是「健康部署期」，主要 feature 改動該排這時候
- 半夜部署的失敗率明顯較高（10% vs 平均 4%）
- 看到自己半夜部署過多 → 警訊，需要強制休息
真實 100 次部署的數據
| 項目 | 次數 |
|---|---|
| 成功部署 | 96 |
| 失敗（CI / token 錯） | 3 |
| 部署完才發現 bug 並回滾 | 1 |
| 導致 production 短暫斷 | 0 |
| 平均部署時長 | 27 秒 |
| 最長部署（重新上傳所有 image） | 2 分 18 秒 |
1 次回滾在 100 次裡是不錯的比率。0 次完全 down 是因為 Pages 採 deployment-as-snapshot 的設計 — 失敗的 deploy 不會覆寫前一個。
結語
Cloudflare Pages 改變了我對「部署」的定義 — 從「謹慎事件」變成「持續節奏」。100 次部署累積出的不只是技術經驗，是對「部署即正常工作流」的內化。第 200 次部署可能會更順、第 500 次可能會發現新模式。記錄是為了在下個里程碑回頭看，知道自己進步了多少。