嗨,世界
Published in

嗨,世界

繼第一篇講述基本概念之後,我們來看看整合模式有哪些,以及整合頻率對於團隊效率的影響。

整合模式

分散式版控讓我們在不互相干擾的情況下進行開發,但最終還是要整合在一起。因此所謂的分支策略其實就是在講『如何整合&何時整合』。

主線整合

直接在本地端 master 開發,完成後提交到主線 (origin master)。

承前文,主線代表了團隊發佈的基準,這裡是建立變更的起點,也應是變更的終點(開發開始 → 開發完成)。接下來用範例來看整個主線整合的運作:

  • 當 Scarlett 想開發時,會在自己的分支上做一些 commit
紅線為 Scarlett 本地端的 master,一個一個紅色長方形是 Scarlett 的 commit
  • 在此同時同事 Violet 對主線做了一些變動,Scarlett 看得到變動,但仍可以在自己的 codeline 上作業不被影響
  • 在某個時刻(希望越快越好),Scarlett 會想把主線的變動整合到自己的 codeline。首先,Scarlett 需要把主線的變動拉到自己的 codeline。
  • Scarlett 必須在自己的 codeline 先整合 Violet 的變動。偶爾在整合時會遇到衝突,如果有一些邏輯上的衝突時,測試就變得很重要
  • 此時 Scarlett 已經在自己的 codeline 完成整合,而這樣提交自己 commit、整合他人 commit 的動作會不斷持續,直到最後工作完成。
  • 當工作完成時 Scarlett 需要把變更整合回主線
    下圖是比較順利的整合情況,有時整合回主線時會發現主線上有新的變更,此時就需要在自己的 codeline 上面再做一次變更的整合,直到主線的變更都已經被整合後才能整合回主線。

要注意的是所謂的主線整合必須要完成上述 1–6 步驟,因為 1–5 步驟時,其他團隊成員從主線是完全看不到新的變更的,唯有完成第 6 步驟把變更整合回主線,才是一個完整的主線整合流程。

在這樣的情境下如果有成員們需要一起協作,但又不想直接透過主線溝通整合,那可以採用 協作分支 的方式(其實就是這兩個成員對這次協作的主線)。

功能分支 Feature Branching

每開發一個(或一小群)功能,即建立新的功能分支,開發完成時合併回主線

  • 當需要開發新功能時,在本地端建立新的功能分支,此分支可以 push 至 shared repo 這樣其他人也都看得到最新變化,同時也不會影響到 mainline
  • 主線如果有變化時,會先反應在 local master,可先以此決定是否整合 這樣的整合只有在功能分支上看得到
local master 有新的變更,整合至功能分支(紫色大塊的變成黃色八角形)
  • 持續開發 & 整合直到開發完成,就可以整合回本地端 master 然後再做主線整合。

功能分支目前算是業界產品開發的標準配備,在討論另一種做法 持續整合 之前,先來看看整合頻率的影響。

整合頻率

State of Dev Ops Report 顯示整合頻率與團隊效能為有正面的關係。接下來透過不同頻率的整合來看看為什麼會有如此的影響。

低整合頻率

  • 一開始 Scarlett 與 Violet 各自在自己的 codeline 上開發
  • 開發途中另一個成員 Garyham 對主線提交了變更 M1
  • Scarlett 與 Violet 看到了變更後分別整合至自己的 codeline,至此都相安無事
  • 大家分別持續的開發,直到 Scarlett 開發完畢提交變更給主線

然後 Violet 就會發現主線多了一大包,包含了 S1-S5 的變更,必須要與自己的 V1-V6 整合

『誰叫你不早點 push』Scarlett 說。

高整合頻率

假設 Scarlett 跟 Violet 作法與前例相反呢?如果他們每次 commit 都直接整合至主線

  • Scarlett / Violet 同時進行開發,Violet 先有了第一個 commit 就直接整合至主線
  • Scarlett 想提交 S1 但發現主線有變更,於是先整合至自己的 codeline 再提交整合後的變更
  • Scarlett 下一個變更在 push 到主線時因為主線上沒有 Violet 或其他成員的新的變更,所以異常順利。而 Violet 想提交 V2 時發現主線有 S1-S2,於是進行整合後再提交至主線
  • 中間 Grayham 突然飛進一個 M1 也是差不多的處理狀況
  • 總之大家就是很高頻率的使用主線在溝通新的變更

高/低頻率整合的比較

前面兩種截然不同範例的整合過程大略如上圖,影響最大的是整合(黃色八角形)的大小,越大的八角形代表越多的整合工作。如果功能切分的乾淨,兩個不相干功能的整合不管再怎麼大可能也會很輕鬆。但如果剛好碰到同樣的區塊,又都在大改架構,那就只能自求多福希望自己是先 push 的那個了,動作慢的倒霉鬼可能需要花上一天甚至數天來處理整合上的問題,這也衍伸出一個名詞 — 『整合恐懼』。

[整合恐懼]當你遇過幾次上述數小時甚至數天的整合時,就會開始害怕整合這件事,人們面對害怕的事情最直覺的解決方式就是逃避,也就是更少的整合。然後就進入惡性循環:更少的整合、更大包更久的整合、更少更少的整合、更大包更大包的整合。
更少的整合也意味著大家更不願意花時間在重構上,因為重構也需要整合,長期來說會造成程式碼品質下降,功能開發變慢等負面效果,然後就是更長時間的產品開發、更長時間的整合...
解決方式嘛,就反向操作。如果整合會痛,那麼就把痛分散在各個 commit 上,寧願一次被一隻蚊子叮,而不要累積很久被一隻虎頭蜂叮(好這比喻很爛)。這樣不僅比較不會痛,每次整合的穩定性也會提高,一個整合突然要多花半天一週處理的情況會減少,對於開發時程的掌握度也會提高。

從另一個角度來看,從衝突產生到被對方發現的時間如下圖

可以看到低頻率時整個衝突從產生到被發現會經過一整個功能開發的時間,這中間還會累積更多的不同衝突。高頻率時這樣的衝突累積相較會小很多,搭配健康分支概念,就可以把需要處理的範圍限縮在當下 commit 的變更內。

其實整個產品開發同時也是個溝通的過程,有時候我們需要透過版控工具做溝通。當整合頻率高時,其他人比較容易知道彼此的進度以及掌握整體的變化。當我們需要更高頻率的整合並且同時維護主線健康度時,就很自然的會需要縮減功能大小。這會附帶其他好處:更快的發佈、更快的使用者回饋、更快的學期、決策以及下一次迭代。

小結

講了主線整合以及目前主流的功能分支,並且探討整合頻率對於團隊效率關係,下一章將會討論持續整合以及其與功能分支的比較。

--

--

追蹤我們的粉絲團以獲得最新發文通知 https://www.facebook.com/thingsaboutwebdev/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store