昨天有朋友在公眾號(hào)私信問(wèn)我?guī)讉€(gè)關(guān)于代碼分支管理的問(wèn)題，這幾個(gè)問(wèn)題是我去年寫的《在團(tuán)隊(duì)中使用GitLab中的Merge Request工作模式》一文結(jié)尾時(shí)拋出的幾個(gè)問(wèn)題：

• 如果系統(tǒng)上線后有緊急Bug需要處理，這個(gè)流程應(yīng)該怎樣去調(diào)整？

• 每個(gè)任務(wù)都在單獨(dú)分支并行開(kāi)發(fā)，這時(shí)如果A和B都依賴C開(kāi)發(fā)的一個(gè)模塊，應(yīng)該怎么解決？

• 理論上Issue管理員和開(kāi)發(fā)人員都可以進(jìn)行創(chuàng)建，什么樣的Issue可以有開(kāi)發(fā)人員來(lái)創(chuàng)建？

這幾個(gè)問(wèn)題在《敏捷下的需求和代碼分支管理》一文中其實(shí)已經(jīng)給出了答案，時(shí)隔兩個(gè)月，管理方式又有了些調(diào)整和改進(jìn)。我覺(jué)得還是有必要單獨(dú)寫一寫。

總體的流程沒(méi)有大的變化，還是使用Tapd來(lái)管理需求和缺陷，使用Gitlab來(lái)管理代碼的分支，但有幾個(gè)小的調(diào)整：

• 迭代周期

• 需求文檔

• 分支管理

迭代周期調(diào)整

之前是以一周做為一個(gè)迭代周期，實(shí)踐中發(fā)現(xiàn)，以周為單位，粒度還是太大，有時(shí)候緊急上線一個(gè)功能或是修復(fù)Bug，連續(xù)幾天都會(huì)有發(fā)布，甚至一天內(nèi)還有多次發(fā)布。目前迭代遵循著以下幾點(diǎn)：

• 因?yàn)楣δ馨l(fā)布時(shí)間的不確定性，需求的安排還是以周為單位來(lái)計(jì)劃

• 一個(gè)完整功能提測(cè)通過(guò)后，立即發(fā)布上線

• 緊急Bug修復(fù)完成后，立即發(fā)布上線

像這樣調(diào)整，產(chǎn)品的迭代會(huì)更加敏捷，同時(shí)也對(duì)整個(gè)團(tuán)隊(duì)提出了更高的要求，怎樣在這樣高速迭代的過(guò)程中，還保證產(chǎn)品的穩(wěn)定性？

需求文檔的調(diào)整

自從以任務(wù)為導(dǎo)向調(diào)整成需求為導(dǎo)向時(shí)，就已經(jīng)意識(shí)到需求的重要性，同時(shí)也面臨一個(gè)問(wèn)題：需求文檔誰(shuí)來(lái)寫？

一些大公司的研發(fā)團(tuán)隊(duì)，配置齊全，有專職的需求分析師，而像我們這種小的創(chuàng)業(yè)型產(chǎn)品團(tuán)隊(duì)，我希望每個(gè)人都能是需求分析師。

在調(diào)整為需求導(dǎo)向的開(kāi)始階段，是我一個(gè)人在寫需求的詳細(xì)描述，一旦精力分散，就會(huì)導(dǎo)致有疏漏，效果不是很好。現(xiàn)在我要求團(tuán)隊(duì)成員每個(gè)人都參與寫需求，在接到任務(wù)時(shí)，必須先思考，把自己到理解寫出來(lái)，然后才開(kāi)始開(kāi)發(fā)。

我會(huì)對(duì)需求做review，也會(huì)讓經(jīng)驗(yàn)豐富的程序員來(lái)做review，找出遺漏的點(diǎn)和錯(cuò)誤的點(diǎn)進(jìn)行補(bǔ)充和改正。

讓每個(gè)人都參與需求的編寫有兩個(gè)好處：

• 可以改掉程序員不喜歡思考，拿到任務(wù)就直接寫代碼的壞習(xí)慣

• 程序員有了自己的思考，并且形成了文字的輸出，對(duì)需求的理解會(huì)更加的深刻，產(chǎn)出的質(zhì)量會(huì)有提高

另外，需求文檔的工具，也從原來(lái)直接在Tapd中編寫，調(diào)整到了語(yǔ)雀。在這里強(qiáng)烈推薦下語(yǔ)雀，理由如下：

• 編輯器，對(duì)開(kāi)發(fā)人員非常友好，真正意義上的所見(jiàn)及所得

• 文中可以直接嵌入Office文檔和視頻（支持本地視頻上傳），在線瀏覽和觀看

• 整個(gè)文檔可以導(dǎo)出成PDF，不知不覺(jué)的就可以寫一本電子書(shū)

分支的調(diào)整

之所以要做調(diào)整肯定是遇到了問(wèn)題，所以，先說(shuō)問(wèn)題：

需要更小迭代的發(fā)布，常常A功能已經(jīng)在測(cè)試中，這時(shí)B功能并入主分支進(jìn)行測(cè)試，A功能測(cè)試完，B功能還在測(cè)試中，這是如果發(fā)布，會(huì)導(dǎo)致沒(méi)有完成測(cè)試的B也發(fā)布了，而我只想發(fā)布A

客戶A使用的是v6.7.5版本，而現(xiàn)在最新的版本已經(jīng)迭代到了v6.8.0，在v6.7.5上發(fā)現(xiàn)的Bug應(yīng)該怎么辦？

引入release分支

• 創(chuàng)建release分支做為發(fā)布分支，該分支設(shè)置為只能管理員提交代碼

• 需求開(kāi)發(fā)完成后，會(huì)merge到master分支進(jìn)行測(cè)試

• 測(cè)試通過(guò)的提交，并到release分支，進(jìn)行再次驗(yàn)證，驗(yàn)證通過(guò)，發(fā)布上線

引入release分支可以雖然在操作步驟上帶來(lái)了一些復(fù)雜度，但是可以確保能夠以最小粒度發(fā)布。

引入Tag

在release分支發(fā)布上線后，以發(fā)布的版本號(hào)為名稱在GitLab中打一個(gè)Tag，這樣就可以解決上面的問(wèn)題2，分為兩種情況：

以v6.7.5的Tag創(chuàng)建分支來(lái)修復(fù)Bug，修復(fù)后直接在該分支進(jìn)行測(cè)試，驗(yàn)證通過(guò)后發(fā)布，最新版本如果該Bug已經(jīng)修復(fù)，則直接更新Tag

以v6.7.5的Tag創(chuàng)建分支來(lái)修復(fù)Bug，修復(fù)后直接在該分支進(jìn)行測(cè)試，驗(yàn)證通過(guò)后發(fā)布，最新版本如果沒(méi)有修復(fù)該Bug，將修復(fù)Bug的提交合并到主分支，然后更新Tag

同樣，當(dāng)程序發(fā)布到docker容器中后，在容器的私有倉(cāng)庫(kù)中也打上以版本號(hào)命名的Tag，可以便于升級(jí)后的回滾。

總結(jié)

工具和流程都只是輔助手段，目的是為了團(tuán)隊(duì)能夠更好的溝通協(xié)助，能夠持續(xù)地有高質(zhì)量的產(chǎn)出，千萬(wàn)不能本末倒置。

最后，祝大家端午節(jié)快樂(lè)！

---

.NET社區(qū)新聞，深度好文，歡迎訪問(wèn)公眾號(hào)文章匯總?http://www.csharpkit.com?

總結(jié)

以上是生活随笔為你收集整理的不断进化的分支和需求管理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。