從本機到 Cloudflare Pages：分支策略與 Zero Trust — 編譯摘要
濃縮
核心結論
- 預覽環境沒更新的根因通常是推錯分支——正式站綁 main、預覽站綁 dev，直接 commit 到 main 不會觸發預覽建置。
- 團隊應建立「先推 dev 再上 main」的鐵律，所有修改先到預覽環境驗證再合併。
- [[Zero Trust Access]] 的 Email OTP 驗證是預覽環境存取控制的實用方案，24 小時有效期在安全與便利之間取得平衡。
關鍵證據
- 實際案例：團隊成員照片更新後推到 main，預覽站完全無反應，需 cherry-pick 回 dev。
- 三條部署鐵律：先推 dev 再上 main、認明預覽環境後綴、記得收驗證信。
質疑
依賴哪些前提假設？
- 假設團隊所有成員都理解並遵守分支策略。
- 假設只有兩個環境（預覽 + 正式），沒有 staging 或 QA 環境的需求。
- 假設 Email OTP 的延遲（等信、輸入驗證碼）不會嚴重影響開發效率。
換產業/規模/技術棧還成立嗎？
- [[分支部署策略]]在所有 CI/CD 平台都適用，但具體的分支綁定方式依平台而異。
- 大型團隊可能需要 feature branch → dev → staging → main 的多層策略。
- 非靜態網站（如有資料庫依賴）的預覽環境設定更複雜。
反例或邊界條件
- 緊急修復（hotfix）時，「先推 dev」的流程可能太慢，需要例外機制。
- 單人開發者可能覺得分支策略是不必要的開銷。
對標
其他領域的類似現象
- 新聞業的編輯流程：稿件先經過編輯台（dev）審核，確認後才上版（main）。
- 藥品上市流程：先在臨床試驗環境驗證，通過後才正式上市。
知識可遷移到哪些場景
- 任何有「草稿 → 審核 → 發布」流程的系統都適用此模式。
- 內容管理系統的預覽功能設計。
關聯概念
- [[分支部署策略]]
- [[Zero Trust Access]]
- [[預覽環境存取控制]]
- [[Cloudflare Pages]]
- [[部署流程規範]]
![]()