1.前言

在***專案開始之前，整個專案組的版本控制工具都是採用的svn，程式碼合併以及釋出工作都是由開發、運維來控制的，自***專案作為一個新專案啟動，版本控制工具就由svn換成了git，我們考慮到如果git程式碼合併以及線上釋出許可權收歸測試來掌控，一是可以控制上線釋出的頻率，防止產品隨意插單，二是上線由QA來控制能夠有效保證上線質量；既然對產品質量有利無害，那我們就妥妥的幹起來。在這裡我就介紹下在QA主導下的釋出流程演進過程中發生的那點事。

2.前期專案的情況:

首先介紹下***專案的測試流程，我們測試流程一共分4個環節:

1)        測試開始，把feature開發分支程式碼合併到test分支，

2)        把develop分支程式碼釋出到測試環境進行迴歸測試，測試完畢之後把develop分支合併到master分支；

3)        把master分支釋出到線上確認環境測試；

4)        把master發線上，在線上再確認一遍；

具體的git分支版本管理流程如下:

我剛開始接手釋出的時候，git程式碼合併、釋出上線的許可權是分配給了專案組的所有測試人員，合併程式碼、上線釋出大家都能操作，在這個過程中出現了以下問題:

1)        在feature→test→develop→master這個合併程式碼過程中經常出現每一步都有程式碼衝突的情況，每天花費在解決衝突上的時間較長，極大的耽誤開發、測試的時間，一定程度上降低了工作效率；

2)        介面釋出上線過程中由於等待所有介面測試完畢，導致過一次釋出了26個介面，合併解決衝突就弄了2天，同時也造成了極大的上線風險；

3)        針對介面上線，由於DBA沒有提前稽核好sql、運維沒有修改好配置和調數、運營沒有提前配置好許可權都會延遲介面上線時間，進而延遲客戶端發版；

4)        從一個分支合併程式碼到另外一個分支，後臺普通採用cherry-pick的方式來合併，針對提交次數少的情況下問題不大，但是對於大的功能有幾十個提交，採用這種方式極易會丟失版本；

5)        從週一到週五隨時提需求隨時發，造成釋出頻率過高，給線上質量帶來一定的隱患；

6)        由於沒有提前掌握每天釋出的需求數量，導致有時候一天一個上線需求都沒有，有時候一天很多需求堆積上線，需求太多釋出時間就會拖的很晚，而太晚釋出時功能相關人員不一定都在，這樣就可能會導致當天不能釋出上線，需求延期；  

7)        一次上線的功能太多時，經常出現其中一個功能有問題導致其他所有功能都不能正常上線；

8)        功能測試正常之後，在利用ops系統釋出時即使釋出日誌顯示正常，釋出線上之後也會出現線上問題；

9)        沒有統一的溝通平臺，由於歡樂購專案有4個系統:hyg、notify、api、g，在釋出不同功能時，需要釋出不同的系統，在QA發出釋出郵件之後，只要開發負責人回覆了郵件，QA就默默的釋出了，直到最後大家一起來確認功能，但是這個釋出過程釋出了哪些系統哪些機器大家不可知，出了問題不能及時解決；

3.措施的制定及實施效果

3.1.措施的制定

針對上面的一些問題，在跟開發、測試溝通之後，採取了以下的一些措施:

1)        針對合併、釋出許可權問題，除了合併test分支，合併develop、master分支的許可權全部收回(設定為了保護分支)，只給開發和測試組的leader保留，釋出上線許可權也只給各組leader保留，但是正常釋出只讓專門的釋出人員進行釋出；

2)        針對衝突問題，由於程式碼合併步驟是feature→test→develop→master，並且很多時候在合併之前沒有同步develop分支程式碼，所以只要在第一步出現了衝突，後面很多時候只要是合併都會出現衝突，而且每個測試人員測試進度不同，合併的順序打亂之後也會增加程式碼的衝突概率，所以這裡要求開發、測試每天同步develop分支到本地，develop分支的功能程式碼不過夜，一旦程式碼合併到develop分支之後如果當天不能釋出上線，全部回滾，保證develop分支和master分支程式碼一致，而且在develop分支合併程式碼到master分支的時候都採用 git merge的方式，這樣一是保證程式碼不會挑漏二是能避免合併順序的不同增加程式碼衝突概率三是這種合併程式碼方式更快捷；

3)        針對介面的問題，為了避免功能都堆積到一起釋出，我們採用了一期客戶端介面分多次上線方式，只要功能沒有關聯，測完一批上一批，不等待所有功能在一起釋出，而且每批介面不超過10個，另外很多介面功能涉及到DBA建表、申請物品許可權、線上確認等環節，一天很難全部弄完，為此我們把這些工作都要求在上線的前一天全部做完，保證在上線當天只需要完成在線上確認的工作，另外確保在客戶端發版日提前三天就把所有介面都發布上線，這樣可以讓客戶端發版之前直接在線上進行測試，提前發現線上問題；

4)        為了避免釋出的無序以及經常臨時釋出需求，我們規定常規釋出時間為週二、週四，並且在下午2點之前截止收版本，4點之前釋出；緊急釋出在每天4點之前，並且緊急釋出的需求必須經過產品負責人和開發負責人郵件回覆同意，否則不予釋出；bug修復隨時釋出；

5)        另外我們建立了統一的專案釋出群，並且申請了線上伺服器許可權，在每釋出一個系統時都先發該系統的一臺機器，確認釋出日誌和後臺日誌沒問題，再發布該系統的所有機器，這樣即使出了問題也能提前知道並且讓影響面縮小，並且這個過程的每一步都在群裡說明，讓開發、測試及時檢視日誌，有問題及時回滾修復；

6)        每週五從產品、運營處提前收集下週需要上線的需求，週一把收集到的功能發給整個專案組周知，這樣讓專案組所有人員都掌握髮布進度；

7)        我們開發了產品釋出管理平臺，把所有釋出相關資訊進行記錄，對插單資訊進行統計，預防產品插單；

3.2.實施的效果

• 按照上面措施執行之後，合併中程式碼衝突的情況大大減少，介面上線也再沒有出現一次把所有介面上線的情況，而且都在客戶端發版之前提前上線；跟產品溝通後，現在產品都能遵循常規上線日期為週二、四，插單需求也減少了很多；

• 建立了統一的popo溝通群，釋出的整個過程都讓專案組所有人知曉，通過檢視伺服器日誌，中間出了任何問題都能及時的響應，對線上質量起到了保障的作用。

4.釋出流程改進

但是上面流程執行了一段時間之後，一次對程式碼的回滾事件暴露了這個流程中的一個嚴重問題；

事情發生的經過是這樣的:一般功能在線上確認環境中如果出現了問題我們首先會對master分支相關功能程式碼進行回滾，在git中關於回滾的命令有兩個，一個是git revert，一個是git reset，這兩個命令雖然都可以回滾程式碼，但是起到的作用差別很大，前面說過，我們合併程式碼的方式都由git cherry-pick改為了git merge，由於我們這邊都是並行開發，所以在程式碼合併的過程中經常出現三方合併(參考http://git.oschina.net/progit/中3.2)的情況，針對這種情況如果採用git revert的方式去回滾，很多時候會出現兩個父分支，這樣回滾就非常麻煩，所以一般我們就採用了在本地執行git reset –hard commit_id再通過git push –f的方式推送到遠端，此種方式針對cherry-pick方式合併的程式碼沒出現過問題，但是針對git merge方式合併的程式碼就會導致版本丟失和回滾不乾淨的情況，所以針對這個漏洞，前端同學提出了一個方案:以後每天從master分支新拉release分支，線上釋出用release分支釋出，發完之後大家確認功能沒問題，對master分支進行備份之後，再把release分支合併到master分支，master分支只是作為一個備份分支，不再充當釋出分支的功能，回滾也不採用git reset的方式，而是通過直接發master分支進行回滾；

    修改了之後，新的git版本控制流程如下:

同時，由於流程做了修改，我們之前針對第一版流程的措施中同步develop程式碼的操作也相應的做了更改，以後開發分支都是從master分支上拉取，並且每天同步master分支，為此前端同學利用git 的web hooks功能開發了一個popo提醒功能，一旦程式碼push到master分支，會給相關人員傳送popo資訊，提醒大家同步master分支程式碼；

     經過此次的修改，該流程執行到目前已經有4個多月的時間，釋出過程一直都非常順暢；

5.寫在最後

   上面就是***專案中釋出流程演進的整個過程，這個流程中目前只是應用在運營活動、介面、wap端、後臺釋出中，對於線上釋出流程，每個專案由於實際的開發測試流程不同而不同，把這個過程分享出來，也希望能給大家一點借鑑。