一個危險的等式

我的服務目前的部署設定：程式碼推上主分支 = 觸發自動部署到正式站。 沒有人工審批環節、沒有部署窗口、沒有「週五不上線」的規矩。

在有真實付費使用者的服務上這樣做，聽起來像玩命。它能安全運作的前提，是整條管線上一層層的自動化關卡——今天把這條管線完整攤開。

部署管線解剖

關卡一：變更過濾。 不是所有 push 都觸發部署——只有觸碰到後端、前端、部署設定這些「會影響正式站行為」的路徑才會。純文件改動、只影響 App 的改動（App 走商店審核，是另一條完全獨立的發佈通道）不會驚動部署管線。

關卡二：完整測試 + 型別檢查 + 建置。 1200+ 個後端測試（Day 23 的家底）、App 的型別檢查、前端建置——全部通過才進入部署，任何一項紅燈整條管線停止。這就是為什麼 Day 23 說測試是「敢放手的資格」：這道關卡的硬度直接決定了「push 即部署」是勇敢還是魯莽。

關卡三：部署後健康檢查。 部署完成不等於部署成功。管線會實際呼叫正式站的幾個關鍵端點——健康檢查、核心業務查詢、首頁——驗證全部回 200 才算數。這道關卡的存在理由，前面十天已經講了太多次：有一整類 bug（Day 4 的 SQL 方言、Day 5 的 DDL 型別）在測試環境物理上測不出來，只有真正的正式環境會暴露。部署後健檢是接住這類問題的最後一張網——炸了至少當場知道，而不是等使用者回報。

關卡四：機器數量檢查。 最後一道，也是最有「這個專案特色」的一道：檢查正式站的機器數量，多於一台就自動縮回一台。

為什麼多一台機器是事故

這道奇怪的關卡值得單獨解釋。這個服務的所有排程任務——通知發送、點數扣減、資料回補——都設計成單機執行，沒有跨機去重機制。這是一人專案的務實取捨：分散式鎖、任務佇列那套架構的維護成本，對這個規模是奢侈品。

代價是一條絕對紅線：永遠只能有一台機器在跑。 如果部署過程中平台的自動擴展多開了一台，同一個排程會在兩台機器上各跑一次——使用者收到兩則重複通知是小事，重複扣款是實打實的事故。而且這種問題不當機、不報錯，測試環境永遠單機也測不出來，完全符合「靜默失敗」的經典形狀。所以把「機器數 = 1」寫成部署管線的自動化斷言——每次部署後核對，超了就縮。

這裡有個值得一提的架構決策思路：「不支援多機」不是這個系統的缺陷，是它的規格。 一人專案的架構品質不在於「什麼都支援」，在於「明確知道自己不支援什麼，並且讓越界時有東西擋著」。

「push 即上線」改變的其實是紀律

最後講一個心理層面的觀察。這套管線上線後，我發現真正被改變的是我自己的行為：因為 push 就是上線，「先隨便 commit 一版待會再改」這種習慣自然消失了；想累積幾個改動一起上，就開 feature 分支——主分支永遠保持「隨時可以面對使用者」的狀態。

自動化沒有降低紀律要求,反而把紀律從「靠自覺」升級成「靠結構」。對一人團隊，這正是求之不得的事——自覺會累，結構不會。