自動化代碼釋出系統實作

日常運維問題

在我日常運維工作中，代碼釋出可能是最普遍的一項工作之一，尤其是網頁代碼的更新，碎片化釋出需求非常頻繁。在前期開發人員比較少時，還可以由自己來上伺服器通過腳本來釋出代碼。但随着公司項目的增多，更多的開發人員加入到公司，釋出代碼需求開始增多，這就占用了我大部分時間，經常的被打斷其它工作來釋出代碼，非常地不爽，然後開始想解決方法。

嘗試解決問題

當然，釋出代碼肯定是運維的職責之一了，但頻繁的釋出導緻運維大部分時間浪費在重複的操作上，非常的不值得。基于此，開始限制代碼釋出頻率，要求把不是很緊急的更新延後到一周中的幾個時間點。但實施起來效果不理想，治标不治本，原因是你不能強制把需要立即上線的更改延後。實施這樣的定時釋出，有可能影響項目的快速疊代。

最終解決方案

想到這樣子下去也不是辦法，會造成工作很被動，于是開始着手建立以Web操作方式，結合git,rsync來實作自動代碼釋出。公司代碼管理目前用的是svn，開發人員在釋出前也沒有打Tag的習慣，是以想到分布式的git來完成版本的管理，rsync當然是用來同步代碼到其它伺服器了。附上幾張代碼釋出系統的截圖：

開源技術使用

• rsync:用來同步代碼到伺服器;
• git: 用來标記版本，復原版本;
• tornado: python的一個web構架，提供背景服務;
• angularjs: 前端的一個mvc架構，用來實作浏覽器與後端的互動，使得後端不需要關心前端網頁的渲染，專注後端邏輯的開發。前端和後端通過json資料來通信;
• bootstrap: 讓運維人員寫的網站背景UI也可以很專業。

代碼釋出流程

從流程圖可以看到，我們隻需要把稽核釋出的權限交給開發組負責人，運維隻需要維護系統的穩定，之後代碼釋出就不需要運維來參與了。

以上是整體的流程，現在來說詳細說下具體的邏輯實作：

• 1、開發人員送出代碼更新，主要送出的字段包括“更新理由”，“svn代碼路徑”;
• 2、後端收到請求後，把此資料插入到資料庫，标記此更新單為“等待預釋出環境更新”的狀态;
• 3、背景程序定時查詢是否有等待預釋出環境更新的更新單，如果有，讀取svn路徑，執行svn up更新代碼操作,并标記此更新單為“預釋出環境已更新，等待完成測試”;
• 4、開發人員或者測試人員通過預釋出環境的域名來測試功能是否正常，如果不正常，作代碼修改後送出svn，再到web釋出背景點選“傳回修改”，對svn路徑或者不做任何修改再點選“重新送出”，然後更新單又一次回到”等待預釋出環境更新“狀态。循環3、4步驟，直至預釋出環境測試通過為止;
• 5、在确認測試通過後，開發人員點選”測試通過“，這時更新單進入”等待稽核狀态“;
• 6、負責人确認可以釋出後，點選”審批“按鈕，這時更新單進入”稽核通過，等待執行釋出操作“的狀态。這時,開發人員得到釋出代碼的授權;
• 7、開發人員點選”釋出代碼“按鈕，更新單進入”已執行釋出，等待系統完成釋出“狀态;
• 8、背景程序查詢狀态為”已執行釋出，等待系統完成釋出“的更新單，執行git釋出指令。git指令大概為，進入預釋出代碼目錄，執行git add .;git commit -m "更新原因";git tag 上一次版本号+1，再進入已釋出代碼的目錄,執行git pull同步預釋出代碼目錄的更改。最後調用rsync指令同步代碼到生産環境。

下面是復原流程：

• 1、進入web代碼釋出系統，選擇已釋出的版本，點選“申請復原”;
• 2、負責人稽核此次復原;
• 3、開發人員執行復原操作;
• 4、背景查詢“等待復原”的記錄，假如復原的版本号為18，進入已釋出代碼的目錄,執行git checkout -b 18 18;git checkout 18(這兩條git指令作用為,以tag 18建立分支号為18的分支，并切換目前分支為18)，然後再通過rsync指令來同步代碼到生産環境，這樣就實作了版本的復原。

最後想說的話