iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
Software Development

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

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

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

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

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

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

Day 11:主幹開發的發布方式

團隊持續把程式整合到主幹,主幹上的內容也會跟著改變。準備發布時,需要先選定這次要交付的版本,讓後續提交不會直接改變這次的發布內容,再針對選定的版本完成驗證。 常...

2026-09-25 ‧ 由 Miles 分享
DAY 12

Day 12:持續交付

在說明主幹開發的發布方式時,有提到從主幹或發布分支選定版本的做法。選定版本只是發布準備的一部分,團隊還需要準備成品、環境與部署步驟,並確認這個版本是否能正常部署...

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

Day 13:拆分功能,提早整合

一項功能不必全部做完,才能把程式整合到主幹。先完成的部分,只要所需的程式都已準備好,並通過驗證,確認新增的行為正常、原有功能也仍能使用,就可以先整合到主幹。 在...

2026-09-27 ‧ 由 Miles 分享
DAY 14

Day 14:逐步交付價值

使用者提出一項需求,可能需要多個功能配合才能滿足。例如,為了辨認客戶資料中尚未填寫的欄位,系統需要提供查看清單與未填寫提示功能。 安排交付範圍時,可以先確認使用...

2026-09-28 ‧ 由 Miles 分享
DAY 15

Day 15:功能標誌

在逐步交付價值時,產品經理與團隊需要確認哪些功能先完成、哪些可以延後,也需要考慮功能的開放時間。例如,活動介紹頁需要配合宣傳日期,即使程式提前完成,也要等到約定...

2026-09-29 ‧ 由 Miles 分享
DAY 16

Day 16:功能標誌的實作與管理

在說明功能標誌時,Nathan 團隊已確認活動頁面與首頁入口需要分開控制,並約定設定如何生效、各種組合應有的行為。 開發者要先將這些判斷寫進程式,完成驗證與部署...

2026-09-30 ‧ 由 Miles 分享
DAY 17

Day 17:抽象分支

功能標誌讓程式可以先整合與部署,再依產品安排開放功能。如果要替換既有功能的實作,改版期間仍須維持原本功能運作,也要讓其他開發者能繼續開發依賴它的功能。 抽象分支...

2026-10-01 ‧ 由 Miles 分享
DAY 18

Day 18:依賴注入與新舊實作並存

建立共同介面後,新舊類別可以提供相同的操作,但呼叫端如果仍直接建立某個類別,切換時就得逐一修改。為了讓呼叫端不必隨著實作切換而修改,可以改由外部建立物件,再傳給...

2026-10-02 ‧ 由 Miles 分享
DAY 19

Day 19:透過抽象分支驗證與切換新實作

透過依賴注入讓新舊實作並存後,新寄信程式已經可以整合到主幹,正式功能仍使用原本的方式。在切換之前,團隊需要確認新實作能在實際使用的環境中正常運作。 為了讓測試結...

2026-10-03 ‧ 由 Miles 分享
DAY 20

Day 20:抽象分支中的抽象

抽象(Abstraction)是保留與目前目的有關的重要特徵,省略不需要關注的細節。 抽象分支保留呼叫端需要的共同操作,將具體做法交給實作。新舊實作可以同時保留...

2026-10-04 ‧ 由 Miles 分享