自動化代碼釋出系統實作

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

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

<a href="http://www.centos.bz/wp-content/uploads/2014/09/%E9%A6%96%E9%A1%B5.jpg" target="_blank"></a>

<a href="http://www.centos.bz/wp-content/uploads/2014/09/%E6%89%80%E6%9C%89%E6%9B%B4%E6%96%B0.jpg" target="_blank"></a>

<a href="http://www.centos.bz/wp-content/uploads/2014/09/%E6%8F%90%E4%BA%A4%E4%BB%A3%E7%A0%81.jpg" target="_blank"></a>

rsync:用來同步代碼到伺服器;

git: 用來标記版本，復原版本;

angularjs: 前端的一個mvc架構，用來實作浏覽器與後端的互動，使得後端不需要關心前端網頁的渲染，專注後端邏輯的開發。前端和後端通過json資料來通信;

bootstrap: 讓運維人員寫的網站背景UI也可以很專業。

<a href="http://www.centos.bz/wp-content/uploads/2014/09/%E4%BB%A3%E7%A0%81%E8%87%AA%E5%8A%A8%E5%8F%91%E5%B8%83.jpg" target="_blank"></a>

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

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

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指令來同步代碼到生産環境，這樣就實作了版本的復原。

最後想說的是，運維工作可以是枯燥的，也可以是有趣的。枯燥是因為沒有意識或者懶得把重複的操作通過制定流程來使其自動化，在不斷地把各種在運維工作中占用時間比較多的重複操作通過技術來使得自動化時，我們既高效完成了工作，節省了時間，又能提高程式設計和解決問題的能力，隻有這樣，我們才能讓運維工作變得既有趣又有挑戰性。

本文轉自 msj0905 51CTO部落格，原文連結:http://blog.51cto.com/sky66/1615823