在一個大型團隊中，bug協同管理是一件復雜的事情，我們基于go-git開發實現了通用化的git-poison，通過分布式源碼管理bug追溯、查詢，可復制性高，適用于所有git倉庫，與分支模式和代碼倉庫無關。

前言

在一個大型團隊中，bug協同管理是一件復雜的事情，發布經理要追版本bug，運維同學要評估bug影響范圍，開發同學要在多個開發分支同時修復同一個bug，很容易出現bug漏提交、漏確認等生產安全問題。

本團隊也出現過一起不同分支漏提交bugfix導致的一起P1故障（最高等級），該bug在生產環境進行hotfix時，漏掉了少量集群導致該二次故障。舉個相似的例子，某品牌汽車發現潛在安全隱患進行召回，但卻遺漏了某個小地區，偏偏在遺漏的地區，發生了安全事故導致有人員傷亡。

我們基于go-git開發實現了通用化的git-poison，通過分布式源碼管理bug追溯、查詢，可復制性高，適用于所有git倉庫，與分支模式和代碼倉庫無關。bug管理不依賴人與人之間溝通協調，降低了認知負擔。

Bug為什么重復翻車

任何軟件都會有bug。即使再全面的測試，再細致的代碼review，也不能保證線上的每一段代碼都bug-free。但是已經識別到的bug，為什么還會重復翻車呢？歸根結底，git多分支開發模式會導致bug擴散。引入bug和發現和修復bug的時間異步，口頭溝通確認bug易疏漏。

很多人看到前言的故障可能會認為，這只是“不小心”犯了個錯誤，下次再“細心”一點兒就好了。其實不是的，在百人規模的團隊中，人犯錯可以說是必然的。

圖1 (Baron " the ")

上圖形象展示了人與人之間的協同成本。

10人團隊的整體協同一次的溝通次數為90/2=45次，那么100人則是4650次。這個次數只是相互協同一次，大多數場景下，由于bug和bugfix是隨時出現的，再加上人的失誤 (溝通中忘了某些bug等)，所以一般來講，一個發布流程至少需要前后同步三次，溝通成本巨大。

所以誰能打包票，在這個流程中不犯錯？只有通過工具來進行自動化管理才能保證從“不做錯”到“做不錯”。

幾個典型翻車場景

場景一：未修復bug代碼上線

圖2 發布同學多方協同

微服務化盛行，系統各服務獨立發布，發布owner也會選擇本組比較有經驗的同學，但仍舊不能避免開發與發布之間的信息割裂。該類問題有很多種表現形態，舉例來說：

版本發布同學，作為整個流程的核心人物，在這個繁瑣的流程中極易犯錯。

場景二：已修復bug但沒修全

還有一類情況，就是針對分支開發的代碼漏合。

圖3 分支開發漏合bugfix

某一分支發現bug時（參考上圖branch master），第一時間一定會在master分支上進行修復。然而此時帶有該bug的branch1就被遺漏了。該問題在多個LTS（Long Time Support）分支的開發模式中尤其嚴重，每個版本都需要發布同學double check有無重點bugfix漏合。

場景三：已修復bug線上漏發

這就是前言提到的場景。人為疏漏。

漏發確實是非常大的問題，但是也有客觀原因。面對千萬級別的生產環境，數十年多個生產版本共存，面臨這樣的組合爆炸，人肉確認hotfix發布范圍不遺漏確實是很大的挑戰。

圖4 線上多種環境組合，發布同學易遺漏

如上圖，假如所有集群按物理ENV分為六組（線上生產遠大于此），例子里本次發布bugfix的同學就是漏掉了ENV5的集群，已知bug也剛好在這個分組的集群中再次出現了。

發布卡點Bug信息

因此，應當存在全局角色來維護bug相關信息。任何角色、任何時間、任何地點都能夠編輯和訪問。

無論是devops模式，還是傳統的專職“研發，測試，運維”模式，都會面臨負責發布的負責人，單點評估整個版本的bugfix以及確認未修復bug，充當“人肉”。作為一個分布式系統開發人員，能否使用分布式工具來解決分布式溝通協同的老大難問題呢？

git-poison的出現，不僅能實時在“開發，測試，發布”間同步所有已知問題，還能參與發布卡點，確認當前版本的未修復bug信息，節約人力成本。

圖5 多方調用git-poison滿足需求

如何使用

git-poison基于go-git的分布式源碼管理，實現bug的追溯、查詢和反饋，靈活&&可復制性高，適用于任何開發模式以及任意代碼倉庫。另外，git-poison不依賴人與人之間的協作溝通，減少認知負擔溝通成本，自動化精準召回bug中毒域，實現poison commit發布阻塞。

圖6 git-poison 投毒/解藥/銀針 （yum install git-poison）

對于開發者，只需要記住一件事：抓緊投毒！

回到前言說到的P1故障，使用git-poison就能簡單有效避免“重復翻車”的場景：

如何實現

每一次投毒/解毒，git-poison的poisons遠程git倉庫中都會生成/更新一條對應記錄。不同代碼倉庫對應不同分支，隔離不同源的posions信息。

{??"poison":"1q234tre5467gcs7yui8ew13",??"cure":"9875jgbsw32gtx6djri8sofi0h",??"comment":"[to?#12345678]?service?iohang",??"editor":"Iris",}

check-commit則應用了git原生強大的history tree管理。

圖7 紅色QW為毒藥commit下的git歷史DAG

如上圖，假如我們當前在release分支上，上次的發布commit是B，當前的發布commit是X。通過 git rev-list 可以直接獲取到整個DAG（ Acyclic Graph）。結合git-poison的記錄，若紅色的Q和W是沒有解藥的poison，則git-poison會阻塞本次發布，返回投毒同學以及對應bug的記錄文檔信息。

假如我們在Dev分支上查詢L是否“有毒”，則git-poison會返回“healthy”。

最佳實踐

發布減負

圖8 發布平臺使用git-poison進行卡點

引入git-poison后，在團隊的發布流程中，發布平臺會調用git-poison自動導入本次版本發布的“Bugfix列表”和“未修復Bug列表”，便于發布經理評估該版本的質量風險，無需再口頭追個確認。包括本次發布修復的問題列表，以及是否有未解決的bug。

Before

After

1.發布同學git log兩次發布之間所有的commit

2.發布同學篩選本模塊相關commit

3.拉群一一詢問對應patch owner

1.發布平臺自動調用git-poison導入未修復bug，

發布經理評估發布風險

風險觀測

圖9 git-poison 聯動線上風險展示

運維平臺可以集成git-poison來檢查線上部署的服務版本是否存在中毒情況。線上風險一目了然。尤其是發現一個新bug后，值班同學可以立即投毒，并通過該頁面獲取該bug影響的范圍。

Before

After

1.值班同學發現bug

2.值班同學去代碼倉庫查找引入bug的commit對應時間

3.獲取線上所有模板找到對應的build版本

4.人肉排查該bug是否在對應版本中

1.值班同學發現bug

2.使用git-poison進行投毒查看影響范圍

結語

目前git-poison已經在公司內部開源，團隊已經實現、使用并集成到發布平臺管理Bug一年多。開發同學本地使用順暢，學習成本低，發布流程中多次有效阻塞帶bug的版本，并為定位bug影響范圍提供極大便利。

都說寫代碼容易，修bug難。在一個多人協作大項目中，修完bug還能保證不重復翻車就是難上加難。有了git-poison，相信事情會變的easy and simple。最后希望我們關于git-poison 的實現邏輯可以分享給更多人。