不斷進化的分支和需求管理

昨天有朋友在公衆號私信問我幾個關於代碼分支管理的問題,這幾個問題是我去年寫的《在團隊中使用GitLab中的Merge Request工作模式》一文結尾時拋出的幾個問題:

  • 如果系統上線後有緊急Bug需要處理,這個流程應該怎樣去調整?
  • 每個任務都在單獨分支並行開發,這時如果A和B都依賴C開發的一個模塊,應該怎麼解決?
  • 理論上Issue管理員和開發人員都可以進行創建,什麼樣的Issue可以有開發人員來創建?

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

總體的流程沒有大的變化,還是使用Tapd來管理需求和缺陷,使用Gitlab來管理代碼的分支,但有幾個小的調整:

  • 迭代週期
  • 需求文檔
  • 分支管理

迭代週期調整

之前是以一週做爲一個迭代週期,實踐中發現,以周爲單位,粒度還是太大,有時候緊急上線一個功能或是修復Bug,連續幾天都會有發佈,甚至一天內還有多次發佈。目前迭代遵循着以下幾點:

  • 因爲功能發佈時間的不確定性,需求的安排還是以周爲單位來計劃
  • 一個完整功能提測通過後,立即發佈上線
  • 緊急Bug修復完成後,立即發佈上線

像這樣調整,產品的迭代會更加敏捷,同時也對整個團隊提出了更高的要求,怎樣在這樣高速迭代的過程中,還保證產品的穩定性?

需求文檔的調整

自從以任務爲導向調整成需求爲導向時,就已經意識到需求的重要性,同時也面臨一個問題:需求文檔誰來寫?

一些大公司的研發團隊,配置齊全,有專職的需求分析師,而像我們這種小的創業型產品團隊,我希望每個人都能是需求分析師。

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

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

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

  • 可以改掉程序員不喜歡思考,拿到任務就直接寫代碼的壞習慣
  • 程序員有了自己的思考,並且形成了文字的輸出,對需求的理解會更加的深刻,產出的質量會有提高

另外,需求文檔的工具,也從原來直接在Tapd中編寫,調整到了語雀。在這裏強烈推薦下語雀,理由如下:

  • 編輯器,對開發人員非常友好,真正意義上的所見及所得
  • 文中可以直接嵌入Office文檔和視頻(支持本地視頻上傳),在線瀏覽和觀看
  • 整個文檔可以導出成PDF,不知不覺的就可以寫一本電子書

分支的調整

之所以要做調整肯定是遇到了問題,所以,先說問題:

  1. 需要更小迭代的發佈,常常A功能已經在測試中,這時B功能併入主分支進行測試,A功能測試完,B功能還在測試中,這是如果發佈,會導致沒有完成測試的B也發佈了,而我只想發佈A
  2. 客戶A使用的是v6.7.5版本,而現在最新的版本已經迭代到了v6.8.0,在v6.7.5上發現的Bug應該怎麼辦?

引入release分支

  • 創建release分支做爲發佈分支,該分支設置爲只能管理員提交代碼
  • 需求開發完成後,會mergemaster分支進行測試
  • 測試通過的提交,併到release分支,進行再次驗證,驗證通過,發佈上線

引入release分支可以雖然在操作步驟上帶來了一些複雜度,但是可以確保能夠以最小粒度發佈。

引入Tag

release分支發佈上線後,以發佈的版本號爲名稱在GitLab中打一個Tag,這樣就可以解決上面的問題2,分爲兩種情況:

  1. v6.7.5Tag創建分支來修復Bug,修復後直接在該分支進行測試,驗證通過後發佈,最新版本如果該Bug已經修復,則直接更新Tag
  2. v6.7.5Tag創建分支來修復Bug,修復後直接在該分支進行測試,驗證通過後發佈,最新版本如果沒有修復該Bug,將修復Bug的提交合併到主分支,然後更新Tag

同樣,當程序發佈到docker容器中後,在容器的私有倉庫中也打上以版本號命名的Tag,可以便於升級後的回滾。

總結

工具和流程都只是輔助手段,目的是爲了團隊能夠更好的溝通協助,能夠持續地有高質量的產出,千萬不能本末倒置。

最後,祝大家端午節快樂!

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章