[[186113]]

正好這周公司大群里因為代碼分支管理有個小小的爭論，所以就先順著這個話題往下寫。當(dāng)然，從技術(shù)的角度看，***的結(jié)論總是沒有哪個方式是對的，哪個方式是錯的。所以一切還是要看使用的人或團隊。就想屠龍刀落入不同的人手里威力是完全不同的。

Git分支管理策略

Git的分支管理策略，通常的做法有兩大“派系”：Git One Track以及Git flow。當(dāng)然很多人也會混用這兩種方式。但是需要澄清一下的是，分支管理不是為了團隊“分豬肉”用的，而是參照團隊的開發(fā)習(xí)慣，管理方式做的選擇。前面的文章也提過，一個Scrum Team***的規(guī)模在7個上下。千萬別因為團隊規(guī)模比較大，為了簡單管理，讓一個大的團隊分出多個分支，然后讓不同的小組各自去開發(fā)。如果是這樣，在同一個產(chǎn)品上(***在同一個可運行的包上)做代碼合并，將是個考驗?zāi)阈呐K能力的時候。

團隊的切分

我們總會遇到需要開發(fā)一個比較大的產(chǎn)品的時候，如唯品會要做個訂單系統(tǒng)，不可能由7個開發(fā)+測試就能搞定的。那么是否組織一個幾十人的團隊一起做呢?我個人的理解是，還是7人的原則，先從產(chǎn)品入手，將一個大的產(chǎn)品想辦法拆分成多個小的產(chǎn)品，不同的小產(chǎn)品間有清晰的接口，這樣以小產(chǎn)品的規(guī)模來考慮組建團隊。每個小產(chǎn)品的團隊就可以各自考慮自己的代碼分支管理策略了，同時讓小產(chǎn)品變成一個可以獨立運行的交付物，可以獨立做到自包含、自測試，從而做到團隊自管理。

Git One Track

One Track通俗來講，就是整個Scrum Team基本都是圍繞Dev分支(或一個版本分支)在開發(fā)。無論是每個新的特性也好，修復(fù)bug也好，都是在這一個分支上。當(dāng)然對于同時需要維護多個版本的時候(不是多個特性)的時候，我們需要在多個版本上開發(fā)。不過這里需要強調(diào)的是，什么時候開出一個版本分支出來需要謹(jǐn)慎，因為當(dāng)需要修復(fù)一個問題或增加一個新的特性的時候就需要人工在不同的分支上都做一次。***的做法是，當(dāng)一個版本基本穩(wěn)定下來，從產(chǎn)品的角度看這個版本只是進入維護周期的時候，就可以開出一個新的版本分支?；蛘呤?**的代碼都是在Dev分支上，當(dāng)一個版本進行維護期時就開出一個維護分支出來。下圖為one track的示意圖。

one track

One Track***的特點是:

• Scrum Team都是工作在一個分支上
• 管理簡單，通過一個Jenkins的job就可以完成CI/CD
• 每次提交代碼前的pull都有可能沖突，如果不同的成員工作在相通的文件上的話
• 為減少沖突，操作經(jīng)驗通常是建議經(jīng)常pull，不可長時間本地工作
• 每次提交都要確保jenkins的build->Test等job都是必須通過
• 每次提交都是小粒度的Task，而不是大段大段的代碼。每個小的task都是runnable的，確保測試容易立即跟進

某種程度上，對于版本策略的選擇與團隊中開發(fā)與測試的配合模式有一定的關(guān)系

Gitflow

Gitflow 通常有個理念是任何變更都是一個分支，無論是一個feature還是一個hotfix，都應(yīng)該以分支的方式進行。這種方式也受到不少人推崇。包括很多工具如Sourcetree也是直接內(nèi)嵌支持。這個方式從管理上似乎是比較干凈的，但是實際上容易進入一個誤區(qū)從而造成代碼merge的麻煩更多。具體什么是Gitflow這里就不啰嗦了，可以看看下面這個圖：

gitflow

Gitflow的容易造成的誤區(qū)：

• 按照人來開分支，目的是為了解決人與人開發(fā)間的沖突。這樣做***的根源在于將工作“分豬肉”，開發(fā)間存在某些配合的局限等。
• 需求/設(shè)計管理的缺陷造成將每個feature劃分的太大，一個feature要做一周甚至一個月，從而造成該分支與主體脫離太久，不同的分支間沖突太大
• 超前規(guī)劃，通常為了某種目的，不是開發(fā)當(dāng)期發(fā)布版本的內(nèi)容，而是開始做后面幾期或更長遠(yuǎn)的規(guī)劃的功能。我們有一種說法叫做“不要過度設(shè)計”，但是對于開發(fā)而言，更要做到“不要過度開發(fā)”

Gitflow從管理上還需要注意額外的成本，包括需不需要給每個feature分支配置相關(guān)的jenkins的CI/CD，測試的跟進如何配合特別是測試是與開發(fā)同步的情況，容易造成團隊的沖突太多因為在一個分支上測試是好的，回到主分支的時候有可能需要重新測試或則測試不通過。似乎這種方式更合適自動化測試比較高，或者適合測試與開發(fā)是有明顯的界限的團隊(但是正如我前面文章提到的我是反對開發(fā)與測試間的提測的理念的)。

***，還是那句話，沒有***的方式，只有最合適的方式，一切都要看團隊的磨合。

版本的管理

無論什么樣的開發(fā)模式，什么樣的代碼管理策略，***都是要發(fā)布版本的。所以版本的管理尤為重要。但是這里有個誤區(qū)，版本管理通常被認(rèn)為是發(fā)布。其實版本管理更多是體現(xiàn)在發(fā)布后如何推廣、如何維護、如何為下一個版本奠定基礎(chǔ)的。就是因為很多人誤以為版本管理就是一次發(fā)布，所以為了避免升級管理等麻煩，總是希望能發(fā)布一個穩(wěn)定的版本就可。然后就有了一個比較可笑的問題，什么時候是“***一個版本”。

如果從產(chǎn)品生命周期來看，所謂的“***一個版本”則意味著產(chǎn)品即將走向“滅亡”。而真正富有生命力的產(chǎn)品則是體現(xiàn)在了版本不斷的推陳出新上。

那么什么是版本管理呢?我的理解是體現(xiàn)在以下幾個方面

• 每個版本都能體現(xiàn)一個明確的目標(biāo)，具體完成什么的功能，或者達成某方面的改進如性能KPI等(或者如SRE上所說的KPO)
• 每個版本都應(yīng)該有對應(yīng)的推進計劃。因為每次有的新版本總會遇到保守的團隊問“是否已經(jīng)有人用過了?是否是穩(wěn)定的了?”但是如果沒有先行者做嘗試，沒有友好用戶做小白鼠，那么這個問題將是無解的。所以，每次出版本都需要有合適的先行推廣的對象，以某種方式推進他們做***次的嘗試，當(dāng)然以什么方式就考驗產(chǎn)品團隊各顯神通了。
• 要留一手?？此泼看伟l(fā)布一個版本，但是實際上從版本管理的角度你需要手里有一個“回退版本”。畢竟不是每個版本都能如愿成為穩(wěn)定版本的，所以為了避免無可用版本，在發(fā)布推廣版本的時候需要有明確的版本回退策略。這個對于提供開發(fā)框架的產(chǎn)品尤為重要。如果出現(xiàn)兼容性的改動，很可能是無版本可用的，這個風(fēng)險必須謹(jǐn)慎對待。
• 多個版本的維護。既然為了避免風(fēng)險需要推廣、試用多個版本，那么同時也會帶來副作用，那就是生產(chǎn)上同時運行著多個版本，對于維護、支持等造成一定的壓力包括時間、人力和成本等。所以在通過不同的版本的試用后，需要明確出某個可以穩(wěn)定的版本，并推動升級將版本歸攏到該穩(wěn)定版本上來。一般這種做法叫做“版本基線歸攏”。
• 對于Scrum模式下，我們更強調(diào)每個sprint都應(yīng)該有個可以運行的版本。但是是否每個版本都需要去正式發(fā)布出來給大家用呢?其實不是，在操作上可以針對每個迭代發(fā)布版本，但是真正推送給大家使用可以根據(jù)各方面的情況決定。如有可能功能只是實現(xiàn)一小塊未完整(不代表不可運行，只是實現(xiàn)場景未完整)，則該版本只是內(nèi)部版本。
• 對于版本的監(jiān)控問題。特別是通用軟件如基礎(chǔ)框架軟件等的使用上，一定需要有某種手段監(jiān)控出來有多少個版本正在生產(chǎn)上運行。同時能立即找出對應(yīng)的版本的使用者。這樣當(dāng)出現(xiàn)問題的時候，能***時間找到使用者做處理。同時也能很好的計劃出下個版本誰是最合適的試用者。我們的做法是通過埋點的方式將信息落到文件，再匯集到APM軟件上做查詢和展示。

版本號的管理

似乎這個沒什么需要說的，不就是定個版本號碼如1.0等不就可以了么?其實這個問題，我們部門內(nèi)部還是有過不少的爭論的。主要問題體現(xiàn)在了是用3位編碼格式還是4位編碼格式。雖然本質(zhì)上不會有大的區(qū)別，大多體現(xiàn)在了人的心理上的區(qū)別上。如1.0.1和1.1.0，大多數(shù)人還是覺得1.0.1變化小些使用上能更安全些。實際上，有可能反而是1.0.1變化更大些，因為定義這個版本號的人，本身就有誤導(dǎo)他人的意味在。所以對于版本號的格式的使用上，還是有比較明確的規(guī)則信息比較好。我們目前的操作規(guī)則如下，供大家參考：

• 以3位的編碼方式管理, x.y.z。
• X代表大版本變化，不同的大版本間可以是不兼容的。如1.0.0和2.0.0是不兼容的。
• Y代表是feature版本，這個版本變化說明有新的特性引入，不同的版本間相同的特性是兼容的。
• Z代表hotfix版本，解決的是bug，不會出現(xiàn)任何新的功能。不同的版本間是完全兼容的。

多版本造成的坑

為了避免風(fēng)險，同時維護著多個版本卻也同時存在這另外一個風(fēng)險，那就不同版本間的兼容性風(fēng)險。如一個客戶端與服務(wù)端的程序，不同的客戶端版本與服務(wù)端版本間的兼容性就有可能會造成問題。所以在一定時間后，版本收攏很重要。我們就曾經(jīng)遇到過不同的API版本間造成了OOM的問題。對于多個版本的維護，測試同學(xué)在設(shè)計測試點的時候也是需要作為一個重要方面考慮。當(dāng)然如果DevOps做的比較***的，可能終是維護一個版本在線上。但是當(dāng)公司的業(yè)務(wù)部門多，同時業(yè)務(wù)開發(fā)節(jié)奏完全不一致的時候，想維護一個統(tǒng)一的版本是極其困難的，沒有一個強有力的推動力是不可能做到，或許需要CTO這個層次的管理者來推動。

升級路徑

在同時維護著多個版本的時候，需要明確升級路徑策略，讓使用者有個清晰的認(rèn)識版本變更應(yīng)該往哪里走，也讓維護者同時思考什么樣的版本維護是***的。如我們一個產(chǎn)品的升級路徑如下：

1.0.10 ->1.1.1

1.0.10 ->1.1.2

1.0.10 ->1.1.3

1.1.1 ->1.1.2

1.1.1 ->1.1.3

有了明確的升級路徑策略后，測試的同學(xué)也是要跟進設(shè)計不同的路徑的測試點，從而避免因為多版本帶來的各種坑。

【本文是51CTO專欄作者“VIPDOCKER-了哥 ”的原創(chuàng)文章，如需轉(zhuǎn)載請通過51CTO與作者聯(lián)系】

戳這里，看該作者更多好文