每次 Merge
都是一次
賭注

功能只能在正式機上測試,commit 合上去才知道有沒有問題。壞了,整個系統就壞了。組長疲於奔命,工程師也沒有安全感。

現在的流程
💻
工程師完成功能
在本機開發,沒有地方可以完整測試
⬆️
直推 master
沒有緩衝,直接上正式機
高風險
🔥
正式機壞掉
影響真實使用者,組長緊急處理
緊急修復
😰
組長扛所有
測試、審核、修復全部一個人
承 — 問題的根源

為什麼會一直發生?

ROOT 01
沒有測試環境

功能只有在正式機上才能跑完整流程,所以只能推上去才知道有沒有問題。

ROOT 02
沒有分支保護

任何人可以直推 master,沒有審核機制,壞的 commit 沒有攔截點。

ROOT 03
責任不清楚

工程師推完就結束,測試和驗證的責任落在組長身上,形成單點壓力。

三個環境,
各司其職

把風險分散到三個層級。工程師在測試機驗完,組長只需在正式機上線前把關一次。

FEATURE BRANCH
本機開發
feature/xxx
👨‍💻 工程師負責

自由開發,盡情 commit,不影響任何人。完成後開 PR 到 develop。

壞掉代價:無
DEVELOP BRANCH
測試機
develop
👨‍💻 工程師自己驗

自動部署測試環境。工程師在這裡跑完整流程,確認沒問題才發 PR 給 master。

壞掉代價:低
MASTER BRANCH
正式機
master
👔 組長 Approve

Branch Protection 保護。只有組長 Approve 才能 merge,此時功能已在測試機驗過。

壞掉代價:高
開 PR 工程師 Merge
驗證完成 發 PR 給組長
✓ 組長 Approve → 上線
結 — 對團隊的改變

組長從救火員
變成把關者

現在 · Before
組長扛所有
commit 直推正式機,出問題才知道
組長要測試、審核、修復全包
工程師不知道自己的 code 有沒有問題
正式機壞掉影響真實使用者
之後 · After
各司其職
工程師在測試機驗完整流程,自己負責
組長只需 Approve 最後一個 PR
問題在測試機就被發現,不影響正式機
正式機只收驗證過的功能,穩定性大幅提升
推動的四個步驟
01
建立 develop 分支

從 master 分出 develop,作為測試機的部署來源

02
建立測試環境

CI 自動偵測 develop 有新 commit 就部署到測試機

03
保護 master

Branch Protection 設定,只有組長 Approve 才能 merge 進 master

04
建立 PR 習慣

工程師養成 feature → develop PR,驗完再發 develop → master PR