主幹開發是一種讓開發者在一個共同的主幹分支上協作的開發方式,透過把變更拆小、頻繁整合,減少長期分支帶來的整合負擔,並讓程式碼維持隨時可發布的狀態。過去有聽過朋友對於主幹開發的印象是「不開分支」或「直接把程式碼推上主幹」。
「是這樣!但不是這樣!」
要做到這件事會比看起來的難很多。過程中會遇到各種問題與挑戰,例如:如何保護主幹?尚未完成的功能怎麼先合併?長期的改版計劃又該如何逐步進行?
本系列將用 30 天,從基本觀念到實務情境,深入介紹主幹開發的做法、適用條件與取捨,一起重新認識這個看似簡單、卻又值得仔細研究的開發方式。
回顧先前在切換寄信實作的案例中,當需要切換回原本的立即寄送,只會改變後續通知的寄送方式。但先前已排入佇列的任務仍然存在,不會因為切換實作就消失,因此在做還原設計...
今天沒空,只好完全靠 AI 寫… 不然今天是個非常好的主題 功能標誌讓程式可以先整合與部署,再安排功能開放;抽象分支則讓新舊實作並存,完成驗證後再切換。當發...
抽象分支讓呼叫端使用共同介面,新舊實作則可以同時保留,再依需要切換。如果要替換的是分開執行的新舊系統,就需要採取別的手法。 團隊可以先讓新系統接手一部分功能,其...
新舊系統分開執行後,一項需求仍可能需要同時調整新系統與舊系統的程式。如果它們還使用同一份共用程式,團隊也需要決定如何分享更新,以及哪些版本要一起驗證。 多版本庫...
持續整合需要頻繁執行建置與測試。每次只改一小部分程式,卻要等十幾分鐘才能取得結果,就可能讓開發者放慢提交頻率。若主幹上的某次提交造成建置失敗,在結果回報之前,其...
在直接提交與短期分支中提過,主幹更新後,需要先取得更新,重新驗證準備合併的程式。 開發者提出 PR 前,需要先將準備合併的程式與當時的主幹放在一起驗證。測試通過...
需要的介面還沒完成時,可以先約定要傳入什麼、會回傳什麼,再用測試替身測試呼叫這個介面的程式。 測試替身(Test Double)用來在測試中代替程式依賴的物件或...