[[186113]]

正好這周公司大群里因?yàn)榇a分支管理有個(gè)小小的爭(zhēng)論，所以就先順著這個(gè)話題往下寫(xiě)。當(dāng)然，從技術(shù)的角度看，***的結(jié)論總是沒(méi)有哪個(gè)方式是對(duì)的，哪個(gè)方式是錯(cuò)的。所以一切還是要看使用的人或團(tuán)隊(duì)。就想屠龍刀落入不同的人手里威力是完全不同的。

Git分支管理策略

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

團(tuán)隊(duì)的切分

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

Git One Track

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

one track

One Track***的特點(diǎn)是:

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

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

Gitflow

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

gitflow

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

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

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

***，還是那句話，沒(méi)有***的方式，只有最合適的方式，一切都要看團(tuán)隊(duì)的磨合。

版本的管理

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

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

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

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

版本號(hào)的管理

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

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

多版本造成的坑

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

升級(jí)路徑

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

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

有了明確的升級(jí)路徑策略后，測(cè)試的同學(xué)也是要跟進(jìn)設(shè)計(jì)不同的路徑的測(cè)試點(diǎn)，從而避免因?yàn)槎喟姹編?lái)的各種坑。

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

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