iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
Software Development

重新認識主幹開發(Trunk-Based Development) 系列

主幹開發是一種讓開發者在一個共同的主幹分支上協作的開發方式,透過把變更拆小、頻繁整合,減少長期分支帶來的整合負擔,並讓程式碼維持隨時可發布的狀態。過去有聽過朋友對於主幹開發的印象是「不開分支」或「直接把程式碼推上主幹」。

「是這樣!但不是這樣!」

要做到這件事會比看起來的難很多。過程中會遇到各種問題與挑戰,例如:如何保護主幹?尚未完成的功能怎麼先合併?長期的改版計劃又該如何逐步進行?

本系列將用 30 天,從基本觀念到實務情境,深入介紹主幹開發的做法、適用條件與取捨,一起重新認識這個看似簡單、卻又值得仔細研究的開發方式。

參賽天數 27 天 | 共 27 篇文章 | 4 人訂閱 訂閱系列文 RSS系列文
DAY 21

Day 21:抽象分支:資料與介面相容

回顧先前在切換寄信實作的案例中,當需要切換回原本的立即寄送,只會改變後續通知的寄送方式。但先前已排入佇列的任務仍然存在,不會因為切換實作就消失,因此在做還原設計...

2026-10-05 ‧ 由 Miles 分享
DAY 22

Day 22:調整功能發布順序

今天沒空,只好完全靠 AI 寫… 不然今天是個非常好的主題 功能標誌讓程式可以先整合與部署,再安排功能開放;抽象分支則讓新舊實作並存,完成驗證後再切換。當發...

2026-10-06 ‧ 由 Miles 分享
DAY 23

Day 23:逐步替換舊系統

抽象分支讓呼叫端使用共同介面,新舊實作則可以同時保留,再依需要切換。如果要替換的是分開執行的新舊系統,就需要採取別的手法。 團隊可以先讓新系統接手一部分功能,其...

2026-10-07 ‧ 由 Miles 分享
DAY 24

Day 24:單一版本庫與多版本庫

新舊系統分開執行後,一項需求仍可能需要同時調整新系統與舊系統的程式。如果它們還使用同一份共用程式,團隊也需要決定如何分享更新,以及哪些版本要一起驗證。 多版本庫...

2026-10-08 ‧ 由 Miles 分享
DAY 25

Day 25:縮短建置與測試的回饋時間

持續整合需要頻繁執行建置與測試。每次只改一小部分程式,卻要等十幾分鐘才能取得結果,就可能讓開發者放慢提交頻率。若主幹上的某次提交造成建置失敗,在結果回報之前,其...

2026-10-09 ‧ 由 Miles 分享
DAY 26

Day 26:主幹更新後的整合驗證

在直接提交與短期分支中提過,主幹更新後,需要先取得更新,重新驗證準備合併的程式。 開發者提出 PR 前,需要先將準備合併的程式與當時的主幹放在一起驗證。測試通過...

2026-10-10 ‧ 由 Miles 分享
DAY 27

Day 27:依賴尚未就緒時的開發與測試

需要的介面還沒完成時,可以先約定要傳入什麼、會回傳什麼,再用測試替身測試呼叫這個介面的程式。 測試替身(Test Double)用來在測試中代替程式依賴的物件或...

2026-10-11 ‧ 由 Miles 分享