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

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

• 每個任務都在單獨分支并行開發(fā)，這時如果A和B都依賴C開發(fā)的一個模塊，應該怎么解決？

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

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

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

• 迭代周期

• 需求文檔

• 分支管理

迭代周期調(diào)整

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

• 因為功能發(fā)布時間的不確定性，需求的安排還是以周為單位來計劃

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

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

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

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

自從以任務為導向調(diào)整成需求為導向時，就已經(jīng)意識到需求的重要性，同時也面臨一個問題：需求文檔誰來寫？

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

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

我會對需求做review，也會讓經(jīng)驗豐富的程序員來做review，找出遺漏的點和錯誤的點進行補充和改正。

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

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

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

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

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

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

• 整個文檔可以導出成PDF，不知不覺的就可以寫一本電子書

分支的調(diào)整

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

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

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

引入release分支

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

• 需求開發(fā)完成后，會merge到master分支進行測試

• 測試通過的提交，并到release分支，進行再次驗證，驗證通過，發(fā)布上線

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

引入Tag

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

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

以v6.7.5的Tag創(chuàng)建分支來修復Bug，修復后直接在該分支進行測試，驗證通過后發(fā)布，最新版本如果沒有修復該Bug，將修復Bug的提交合并到主分支，然后更新Tag

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

總結(jié)

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

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

---

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

總結(jié)

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

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