最近我們因為一個問題需要加班到半夜。
因為我們的主干代碼里有一個嚴重的問題吠各，需要緊急修復(fù)，這個bug發(fā)現(xiàn)的時間很精妙勉抓，在發(fā)布的前一天夜里走孽。
那一夜，基本上所有的需求都開發(fā)完成了琳状，處于測試狀態(tài)中磕瓷，那么如何去修改這個嚴重的bug呢？開發(fā)說就在主干上改念逞，改完以后測試同學(xué)順便加班把其他需求都測完困食，我們提前一天在半夜強行發(fā)布。
于是測試同學(xué)便需要加班到半夜翎承，那天我不在硕盹，不知道他們有沒有留下沒有技術(shù)的淚水。
其實緊急問題沒有必要合在常規(guī)版本里強行發(fā)布叨咖。
一般的做法是在當前生產(chǎn)的分支修復(fù)問題瘩例，然后把生產(chǎn)分支合回主干。
但我們的情況沒有這么幸運甸各，我們直接在master分支上開發(fā)垛贤，生產(chǎn)的代碼也是master的，這就導(dǎo)致了用單一主干去承載開發(fā)趣倾，測試和發(fā)布3種主要用途聘惦，風(fēng)險很高。
比如一旦生產(chǎn)有問題儒恋，那么就必須去回憶生產(chǎn)代碼的具體版本善绎，能夠回憶出來的話就從那個版本拉一條分支出來修復(fù)問題并測試發(fā)布。然后再去master上把相同的代碼再改一次诫尽，緊急發(fā)布分支就不合回master禀酱。
要是回憶不起來版本號的話，那么就只能加班加點測試完master代碼牧嫉，直接發(fā)布主干剂跟，也就是我們上面發(fā)生的情況。
其實代碼管理也算是范質(zhì)量管理里的一部分。如果團隊規(guī)模比較小的話浩聋，我們可以采用下面的模型
- 主干: 穩(wěn)定的代碼
- 開發(fā)分支: 從主干拉出來观蜗，開發(fā)都提交都開發(fā)分支臊恋，發(fā)布之前將代碼合回主干
- 發(fā)布分支: 開發(fā)分支直接合到發(fā)布分支
- hotfix分支: 緊急bug修復(fù)衣洁，從發(fā)布分支拉，然后合回發(fā)布分支
配合一些持續(xù)集成或者工程化實踐抖仅，穩(wěn)定主干模式可以在短時間極大的提升項目質(zhì)量(前提是當前項目的質(zhì)量有極大的提升空間)坊夫。
- 對主干進行daily build，每天定時自動化回歸
- 每次開發(fā)分支合入主干進行后進行自動化回歸
- hotfix后對hotfix分支進行自動化回歸
自動化用例的組成建議是
- 40%左右的單元測試
- 40%左右的接口測試
- 20%左右的ui測試
建議用例運行時間不超過20分鐘撤卢。
回到上面的問題环凿，如果是穩(wěn)定主干的話，我們可以直接從線上的發(fā)布分支拉出hotfix分支放吩，在該分支上進行緊急問題的修復(fù)智听，修復(fù)后進行自動化回歸，沒有問題的話就合到發(fā)布分支渡紫，發(fā)布到線上到推。最后將修改內(nèi)容同步到開發(fā)分支即可。
有了這樣的代碼管理模型惕澎，測試同學(xué)大概可以避免在夜深人靜強上全量代碼時留下沒有技術(shù)的淚水吧莉测。
