從本機到 Cloudflare Pages：預覽環境的分支策略與 Zero Trust 設定

最近我們在更新公司官網的「關於我們」頁面時，遇到了一個常見的部署問題：程式碼推上去了，但預覽網站卻毫無動靜。

當時我們剛在本機換好幾位團隊成員的個人照，確認沒問題後就順手 git push origin main。等了幾分鐘，重新整理 dev.codotx.pages.dev 這個預覽網址，卻發現畫面上還是舊照片。更麻煩的是，連想直接檢查網站狀態，都被 Cloudflare Access 的登入畫面擋在門外。

排查之後，我們發現這是多數團隊剛導入 Cloudflare Pages 時都會踩到的兩個坑：分支綁定錯誤，以及預覽環境的存取控制。

坑一：推錯分支，預覽環境當然沒反應

這是一個很基礎但容易忽略的設定問題。我們的正式網域是綁定 main 分支，但預覽網址 dev.codotx.pages.dev 其實是綁定另一個獨立的 dev 分支。

當初設定 Cloudflare Pages 時，我們為了區分正式與測試環境，做這層隔離是合理的。結果開發時貪快直接 commit 到 main，導致預覽站點根本不會觸發任何建置流程。

解法：建立明確的分支策略

為了解決這個問題，我們內部統一了開發流程：絕不直接在 main 上開發。所有的修改都必須先送進 dev 預覽，確認無誤後再合併。

如果本機還沒有 dev 分支，第一步就是把它開出來：

git fetch origin
git checkout dev

日常更新只要維持這個節奏：

git checkout dev
git pull origin dev
# ...修改程式碼...
git add <files>
git commit -m "更新團隊成員照片"
git push origin dev

推送後，Cloudflare 就會乖乖抓取 dev 分支的內容，自動部署到預覽網址。如果已經不小心推到 main 了怎麼辦？就像我們這次一樣，直接把該 commit cherry-pick 回 dev 再推一次就好。

坑二：被自家設定的 Zero Trust Access 擋住

搞定分支後，我們想打開預覽網址看看部署結果，結果迎面而來的是 Cloudflare Access 的登入畫面。

這是我們刻意設定的。因為 *.codotx.pages.dev 這種測試網址常常會提早曝光還沒準備好公開的內容或新產品功能，所以我們幫它加了一層 Zero Trust Access 保護。這個立意良好，但當團隊成員急著看結果卻忘記怎麼登入時，就成了開發流程的絆腳石。

解法：Email 一次性驗證碼

其實要過這關很簡單，預覽網址需要特定授權的 Email 才能存取。只要在登入畫面輸入已經建檔的信箱，系統就會發送一組一次性驗證碼 (OTP)。輸入驗證碼後就能順利看到網站，而且授權 24 小時內有效，不會一直頻繁打斷開發節奏。

如果其他團隊成員需要看預覽，只要進到 Cloudflare 儀表板的 Zero Trust → Access 控制 → 應用程式 → 原則 裡，把他們的 Email 加進去就行了。

總結

一個看似單純的「預覽網站沒更新」問題，其實反映了基礎設施設定的細節。這個事件後，我們把官網的部署守則整理成了三條鐵律：

1. 先推 dev 再上 main：所有的修改都先推到 dev 預覽，不允許直接操作正式環境的 main 分支。
2. 認明預覽環境後綴：只有 dev.codotx.pages.dev 會即時反映 dev 分支的修改。
3. 記得收驗證信：存取預覽網址遇到存取控制是正常的，用已授權的 Email 收信即可，需要新增權限就到 Cloudflare 後台加。

這個做法不算完美，偶爾還是會覺得要等驗證碼有點麻煩，但在兼顧開發效率和未公開資訊安全的考量下，它確實是最穩健的選擇。