打造高效小團隊 - 團隊代碼提交流程 && 規範

代碼提交規範 && 升級調整

本系列想跟你們分享一下我近一年的管理經驗，分享一下咱們團隊的一年走來的優化之路「非技術」，讓你們少踩坑，以及如何協做，管理者容易遇到的問題，以及技術上，工做上，如何與同事溝通、跨部門如何溝通有效率、如何分組、站會有沒有用？ 等等，一年到頭，想和你們交流一下經驗。

背景

項目早期

無論前端仍是後端，項目早期，咱們是有 master 被保護分支，以及 dev 測試分支的，咱們的提交流程是：全部人往 dev 合併代碼，進行測試封版，測試經過直接把 dev 合併到 master 進行升級。隨之而來發現了問題：

項目中期

咱們不能保證 dev 上的代碼所有測試經過，由於沒有充足的測試時間，並且不斷有新的提交涌入，dev 直接合併到 master 確定是不夠穩妥的，這樣的 dev 沒有任何意義，隨着研發任務強度愈來愈高，索性廢棄了 dev ，直接合併到 master ， master 分支作持續集成到測試環境，每週二升級生產環境。每週三打 TAG，期間有迭代直接提交，直到下週二繼續升級，若是很是緊急，那就基於 git tag 基礎上修改，提交，升級生產。

反思

好景不長，隨着研發任務的進一步提高，問題接踵而來，新業務測試不熟悉，測試時間長，每週二11點還沒測試完畢，甚至每週二晚9點多才發現某某功能需求有問題，還會有其餘小組影響另外小組的進度（關於小組之後單獨講）。這讓研發叫苦連天。每週二的 升級日 變成了 「加班日」 ，雖然每週只有一天，且次日能夠晚點來上班，可是連續兩週下來，仍是有個別同事出現了嚴重的負面情緒，怕影響其餘人，因此須要迅速解決這個問題。大刀闊斧的調整流程！

參考資料

• 閒魚技術
• 流程規範

上文資料請你們簡單看一看,咱們通過討論作了調整，可是基本原理不變。

調整

研發 隨寫隨提，測試 隨提隨測，運維 隨測隨更。隨時測試，隨時更新，隨時升級生產環境。

協商一個時間點，好比天天 19:30，過了 19:30 的需求、bug，明天在調整，儘早回家休息。

研發職責

研發負責人仍是像之前同樣，多創建一個 dev 分支，用於測試，這裏對 dev 的功能作下說明:

dev 分支

dev 分支就是測試環境，咱們把 CI 從 master 換成 dev

這個分支，不須要有權限控制，研發根據 禪道 或者 card 上的任務，從 master check 出一份分支

以 禪道 bug http://xx.104.96.233:60888/zentao/bug-view-11568.html 爲例

• 咱們爲分支命名爲： fix-bug-11568

• 修復 BUG

• commit 代碼寫好 msg:fix xxx ， merge 到 dev 「fix-bug-11568 分支此時不要刪除」

• 通知相關人士進行測試

• 測試失敗「打回從新提交」，測試成功點擊「關閉」通知研發能夠了。

• 研發發起 PR 從「 fix-bug-11568 分支 （注意！不是 dev）」到 Master 後 「 fix-bug-11568 」由管理員合併並刪除

• 此時 Master 隨時能夠升級到生產。

這樣會比較麻煩，因而參考 閒魚技術 咱們也自研了一套流程工具，具體下次專門出篇文章講講。

研發禁止的

• 禁止從 dev 分支 check 代碼，由於你要保證合併到 master 的只有你本身的，沒有其餘人沒測試的，若是從 dev check 代碼，合併到 master 至關於 dev 合併到 master。
• 禁止 merge dev 到 master ，這樣 dev 分支沒意義。

一些問題

你們可能以爲極爲繁瑣，好比：

• 須要根據 ISSUES 建立分支名稱
• 須要通知測試測試
• 測試須要通知研發成功/駁回 等等。

研發會寫 devops 工具確保你們能逐漸自動化，只是須要一些時間。能夠經過一些 CLI + git 鉤子/ 禪道 發送郵件等等，達到減小溝通成本。

測試職測

目前測試的同事須要收到解決的問題快速進行測試，快速通知研發結果。等待以後的郵件提醒。

運維職測

原有的 CI 腳本有小調整 (dev)，生產升級也有小調整 (不能從 qmenhu 直接拽包)

調整服務器 Git hooks ，當有 push 或 merge 請求，查詢 BUG 編號，是否已經關閉，關閉的 bug 或 feature 才能夠 review -> merge，不然 服務器直接駁回。

總結

一切爲了團隊更高效的解決問題，有充分的的我的時間。

後續任務

--- git hooks 詳情 ---

• cli 程序「詳情看：閒魚技術」

• git hook 「詳情看：流程規範」

• 郵件通知 「減小溝通成本」

• ISSUES 平臺的自動化管理

工具

www.npmjs.com/package/zin…

我把工具發佈在 npm 上了，沒有開源，須要的能夠借鑑一下，下次講的時候，我會抽出一些通用的開源，如今先讓內部 「打磨一下」

預覽

之後單獨抽一章講下，代碼很簡單（5個小時工做量），主講思路，以及如何才能作好簡單的 devops，節省全部人的時間。

原文

github.com/pkwenda/Blo…