❯❯ 團隊用 tag 簽核，我用 main 直推：自動化部署的發布觸發策略與 stacked PR 的暗坑

📍 流水線位置｜入口 → flow → 型別 → mock → 測試 → UI → vibe → 【上線】（部署）

以前手動部署是這樣的：SSH 連上伺服器、拉程式碼、跑 build、重啟服務。這中間只要有任何一步出偏差，正式環境就可能異常，而且事後很難確定線上到底跑的是哪一版。

自動部署的觸發條件通常依團隊運作型態分為兩種常見模式：

公司案：tag 觸發，版本號就是發布指令

在多人的團隊開發情境中，發布時機需要明確的決策點。因此部署流程通常會綁定 Git tag，並遵循 Semantic Versioning （語意化版本）規範，透過標籤後綴控制部署去向：vX.Y.Z-dev-mock 部署到測試環境（執行 mock 模式供流程驗證），vX.Y.Z-dev 部署至正式環境（連接真實後端）。

這樣做最大的優勢在於版本可追溯：tag 是不可變的程式碼快照，想確認正式環境目前跑的是哪版，看最新的標籤就清清楚楚。下 tag 的動作，就代表這次發布通過了人工審核程序。

婚禮系統：main 就是部署線

但在我單人維護的婚禮專案裡沒有用 tag。部署平台直接設定成監聽 main 分支，PR 一合進 main 就立刻觸發部署。

一人專案不需要跨角色協調發布時機。程式碼能合進 main 裡，代表已經通過 Day 24 那兩道關卡，那就直接交付上線。團隊需要 tag 來做權責簽核，但在一人專案裡簽核的人就是自己，這步完全可以省掉。

不過「main 即部署線」也意味著：main 一出事，正式環境同步遭殃。 下面是我在這條流程上踩過的兩大巨坑。

坑一：stacked PR 的合併順序與 base 切換機制

當功能範圍比較大時，我們會用 stacked PR（下游分支 B 切自上游分支 A），但它的合併順序藏著大雷。

有一次，上游分支 A 的 PR 剛合併進 main，我隨手就把下游分支 B 的 PR 也合了。結果踩爆了 GitHub 的機制：下游 PR 的 Base 分支，只有在上游「分支被正式刪除」時，GitHub 才會自動把它重新指向到 main；單純合併 PR 是不會觸發 Base 變更的！

結果分支 B 的程式碼直接併進了已經沒人維護的 feature 分支，main 根本沒拿到這筆變更。連帶 PR 裡標註的 Closes #N 也失效了，因為 issue 的自動關閉只在變更併入預設分支（main）時執行。

正確順序是：先刪除上游分支，再合併下游 PR。

只要上游分支一刪，GitHub 就會自動把下游 PR 的 base 指向 main，這時再合併，程式碼才會真的進到預設分支。

坑二：變更未同步引爆的 DROP migration 事故

這起事故緊接著引爆了下半場。那個沒合進 main 的 PR 裡，剛好帶著一個含 DROP 語法的資料庫 migration，而這個 migration 我偏偏已經手動對正式資料庫執行完了。

於是正式環境還停在舊版程式碼，它要查的資料表卻已經被我刪掉，現場桌次頁面當場拋 500 錯誤！如果只是程式碼沒更新，重開一個 PR 就能修；但這次事故展示的是資料庫結構變更（尤其是不可逆的 DROP）在環境不同步時的破壞力。

為了杜絕這種人為慘劇，事後我立下鐵律：手動執行 Migration 前，必須完成雙重檢查：

1. 變更真的已併入 main（這次就是敗在這步：PR 併進了 feature 分支，main 跟線上都停在舊版，單看「線上 SHA 與 main 一致」反而會被假象騙過）。

2. 正式環境當前運行的 Commit SHA 已跟上 main（透過 gh api 查 Deployment 資訊，防止部署延遲或失敗導致的偏差）。

為了降低人為疏失，後來我把 migration 整合進自動部署管線，讓資料庫 migration 腳本隨部署指令自動執行，只要連線設定不對就立刻中止部署，手動執行 migration 從此成為歷史段。

自動化流程可處理確定性的檢驗工作（如執行 migration、確認連線設定）；但關於「變更合併順序」與「發布時機評估」等判斷，仍需由工程師主導。

上線前檢查清單

發布流程的關鍵檢查項目，我整理成這張部署 Checklist：

• ✔️ 雙重守門全綠： 兩道檢查關卡均順利通過（pre-push 與 CI 機制，如 Day 24 所述）。
• ✔️ Stacked PR 順序正確： 存在 stacked PR 時，遵循先刪除上游分支，再合併下游 PR順序。
• ✔️ Migration / DROP 雙重對帳： 確認變更已進 main，且「正式環境 commit sha ＝ main 分支 HEAD」（缺一不可）。
• ✔️ Tag 格式校驗： 若團隊採用 tag 發版時，確認標籤後綴格式，確保發布至預期環境。
• ✔️ Production 核心路徑 Smoke Test： 部署完成後，對正式環境執行核心路徑驗收（如 Day 15 的驗證邏輯，留意測試環境無法覆蓋的邊界）。

到這裡，從需求輸入到自動化部署的整條軟體流水線已經完全貫通。

當工具與 pipeline 幫我們搞定了 90% 的重複性工作，工程師在這條架設好的流水線裡，真正的不可替代性到底是什麼？下一篇我們來聊聊這件事。

🎒 最小一步｜問自己一題：當正式環境突發異常時，你能不能在 10 秒內確認線上目前跑的具體 commit sha？
📎 本篇證據｜stacked PR 併錯目標事故（PR #60 併進 feature 分支、PR #61 補救，2026-07-12）・DROP migration 先驗 sha 的規矩與部署自動 migrate（deploy-migrate 腳本可在公開 repo 查證）・公司案 tag 慣例屬團隊規範（涉內部不附連結）