代碼上線流程以及版本發佈小結

以前的上線流程很簡單粗暴如圖：

這簡直是災難性質的，上傳 SVN，在測試服務器上看看正在調試的接口沒問題，直接 sync 到線上服務器。代碼沒法回滾，只能覆蓋。而客戶端的同窗須要妥當的 api 做爲調試，最初的作法，他們須要新數據，咱們就須要上線代碼。這很坑爹，也許某人某段代碼正寫了一半，又正好提交。被另一我的上線了，那麼就線上出了嚴重 BUG。對此咱們很頭疼，因此作了以下規劃：

首先創建三個版本庫

1. 開發服務版本庫（對應圖片中 dev，假設爲 http://211.155.84.144/topit_dev）

2. 外測服務版本庫（對應圖中 beta，假設爲 http://211.155.84.144/topit_beta）

3. 線上服務版本庫（對應圖片中 online，假設爲 http://211.155.84.144/topit_online）

可能只分上面三個層級仍是不夠細，可是考慮到公司的實際狀況，這是一個折中方案，後期實際證實穩定性獲得了很大的保障。

而後作了一個根據版本配置指定 api 地址的管理後臺，該 api 用於 app 在啓動之初和啓動以後輪詢請求詢問當前 app 應該請求的api 地址多少。如圖所示

 

實際操做流程以下：

1. 項目起步，規定好該版本的 build 和 version 以後（好比 build=3.2.1&version=400，實際還能夠分得更新好比是 Android 仍是 iOS，具體到哪一個渠道，這裏舉例說明就不細分了），後臺設置該版本的 api 地址爲 dev。

2. 每一個人先將本身的代碼直接 sftp 上傳到本身的測試 vhost 指定的目錄中，進行調試。

3. 調試經過後，將代碼提交到 dev 版本庫，而後鉤子觸發更新到 dev 目錄。而當前 dev 目錄則是咱們內部調試的 api 後端服務的根目錄，客戶端同窗在開發的時候就調用該 api。

4. 開發完畢，內部測試經過，將 dev 目錄的文件 rsync 同步到 beta 目錄，過濾了 dev 目錄的 svn信息

5. 將 beta 目錄提交 svn

6. 再執行 beta 代碼遠程同步腳本，將 beta 目錄的代碼同步到多臺 beta 測試服務器上。

7. 而後根據當前的外部版本號和內部版本，在後臺將其 api 請求地址和圖片上傳地址修改成 beta 服務器相關的地址（圖片簡寫爲1臺服務器）

8. 而後將 app 交給專業第三方測試公司幫咱們測試

9. 測試經過後，對於 bug 咱們則再走一遍前面的 dev 到 beta 的步驟，而後，咱們經過在進入 app 首屏給2000到3000個用戶強制彈窗讓其更新到指定版本。進行灰度發佈。

10. 灰度發佈發現 bug，修復 bug 後再走一遍上面的流程，而後把 beta 目錄的代碼同步到 online 目錄，一樣過濾掉 svn 信息

11. 在 online 目錄作版本提交到 online svn 版本庫

12. 而後再執行 online 目錄代碼遠程同步腳本，將 online 目錄的代碼同步到全部線上服務器上。

13. 而後根據當前的外部版本號和內部版本，在後臺將其 api 請求地址和圖片上傳地址修改成線上服務器相關的地址

14. 最後直接全站提示更新到指定版本。

若是突遇線上有緊急 bug 須要修復，若是預估時間比較長，咱們能夠直接將該版本號下的 api 請求退回到 beta 服務器上，而後在 online 目錄修改完畢，提交 svn，同步代碼以後再從新指向線上服務。

若是遇到某個緊急需求，須要立刻上線的，咱們只能經過單獨 cp dev 下的某一個文件到 online 目錄，而後作好版本控制，緊急上線。實際工做中，這種需求很是常見。作提交信息的填寫就顯得格外重要了。

將來須要作的 api 健康狀態週期性監測，服務器週期性請求每一個 api，而後和規定的正確數據進行對比，若是有問題則發出報警信息，以避免每次都要等到用戶反饋咱們才知道有問題。仍是因爲版本迭代太快，數據結構實時調整是常有的事，開發成本和維護成本比較高，咱們都只能暫時擱淺了。

今天我又把代碼上線流程作了些優化

1.  
2.  
3. "/update/log/path/publish.log"
4.  
5.  
6.  
7. sudo |((svn_diff_size>0));
9. ||
11. ;
12.  
13.  
16. ||v |
19.  
20.  
21. ;(($i == 0));   
22.  
23. cat wc (($num<5)); ;
24.  
25. rsync
26. @$1::topit_online/
27.  
28. sudo |v |v cat   
29.  
30. ;
31.  
32. （腳本地址：https://github.com/zhoumengkang/notes/blob/master/shell/update_to_online.sh）

     

    1. 提交時，修改的文件必須提交，以防出問題不方便回滾

    2. 沒有加入版本庫的文件提示最好添加到版本號，能夠忽略

    3. 版本發佈完畢以後給管理員發送郵件通知