代碼上線流程以及版本發布小結
之前的上線流程很簡單粗暴如圖：
這簡直是災難性質的，上傳 SVN，在測試服務器上看看正在調試的接口沒問題，直接 sync 到線上服務器。代碼無法回滾，只能覆蓋。而客戶端的同學需要穩當的 api 作為調試，最初的做法，他們需要新數據，我們就需要上線代碼。這很坑爹，也許某人某段代碼正寫了一半，又正好提交。被另外一個人上線了，那麽就線上出了嚴重 BUG。對此我們很頭疼，所以做了如下規劃：
首先建立三個版本庫
-
開發服務版本庫（對應圖片中 dev，假設為 http://211.155.84.144/topit_dev）
-
外測服務版本庫（對應圖中 beta，假設為 http://211.155.84.144/topit_beta）
-
線上服務版本庫（對應圖片中 online，假設為 http://211.155.84.144/topit_online）
可能只分上面三個層級還是不夠細，但是考慮到公司的實際情況，這是一個折中方案，後期實際證明穩定性得到了很大的保障。
然後做了一個根據版本配置指定 api 地址的管理後臺，該 api 用於 app 在啟動之初和啟動之後輪詢請求詢問當前 app 應該請求的api 地址多少。如圖所示
實際操作流程如下：
-
項目起步，規定好該版本的 build 和 version 之後（比如 build=3.2.1&version=400，實際還可以分得更新比如是 Android 還是 iOS，具體到哪個渠道，這裏舉例說明就不細分了），後臺設置該版本的 api 地址為 dev。
-
每個人先將自己的代碼直接 sftp 上傳到自己的測試 vhost 指定的目錄中，進行調試。
-
調試通過後，將代碼提交到 dev 版本庫，然後鉤子觸發更新到 dev 目錄。而當前 dev 目錄則是我們內部調試的 api 後端服務的根目錄，客戶端同學在開發的時候就調用該 api。
-
開發完畢，內部測試通過，將 dev 目錄的文件 rsync 同步到 beta 目錄，過濾了 dev 目錄的 svn信息
-
將 beta 目錄提交 svn
-
再執行 beta 代碼遠程同步腳本，將 beta 目錄的代碼同步到多臺 beta 測試服務器上。
-
然後根據當前的外部版本號和內部版本，在後臺將其 api 請求地址和圖片上傳地址修改為 beta 服務器相關的地址（圖片簡寫為1臺服務器）
-
然後將 app 交給專業第三方測試公司幫我們測試
-
測試通過後，對於 bug 我們則再走一遍前面的 dev 到 beta 的步驟，然後，我們通過在進入 app 首屏給2000到3000個用戶強制彈窗讓其更新到指定版本。進行灰度發布。
-
灰度發布發現 bug，修復 bug 後再走一遍上面的流程，然後把 beta 目錄的代碼同步到 online 目錄，同樣過濾掉 svn 信息
-
在 online 目錄做版本提交到 online svn 版本庫
-
然後再執行 online 目錄代碼遠程同步腳本，將 online 目錄的代碼同步到所有線上服務器上。
-
然後根據當前的外部版本號和內部版本，在後臺將其 api 請求地址和圖片上傳地址修改為線上服務器相關的地址
-
最後直接全站提示更新到指定版本。
如果突遇線上有緊急 bug 需要修復，如果預估時間比較長，我們可以直接將該版本號下的 api 請求退回到 beta 服務器上，然後在 online 目錄修改完畢，提交 svn，同步代碼之後再重新指向線上服務。
如果遇到某個緊急需求，需要馬上上線的，我們只能通過單獨 cp dev 下的某一個文件到 online 目錄，然後做好版本控制，緊急上線。實際工作中，這種需求非常常見。做提交信息的填寫就顯得格外重要了。
未來需要做的 api 健康狀態周期性監測，服務器周期性請求每個 api，然後和規定的正確數據進行對比，如果有問題則發出報警信息，以免每次都要等到用戶反饋我們才知道有問題。還是由於版本叠代太快，數據結構實時調整是常有的事，開發成本和維護成本比較高，我們都只能暫時擱淺了。
今天我又把代碼上線流程做了些優化
"/update/log/path/publish.log"sudo|((svn_diff_size>0));||;||v|;(($i == 0));catwc(($num<5));;rsync@$1::topit_online/sudo|v|vcat;（腳本地址：https://github.com/zhoumengkang/notes/blob/master/shell/update_to_online.sh）-
提交時，修改的文件必須提交，以防出問題不方便回滾
-
沒有加入版本庫的文件提示最好添加到版本號，可以忽略
-
版本發布完畢之後給管理員發送郵件通知
-
代碼上線流程以及版本發布小結