關於項目開源
由於挺多同學請求開源此項目，在這里說明一下:其實本人是想開源的，由於是本人寫的第一個運維方面的系統，且寫這個項目的時間時間緊，只達到了可以使用的程度，完全沒有達到開源的要求，希望理解！
日常運維問題
在我日常運維工作中，代碼發布可能是最普遍的一項工作之一，尤其是網頁代碼的更新，碎片化發布需求非常頻繁。在前期開發人員比較少時，還可以由自己 來上服務器通過腳本來發布代碼。但隨着公司項目的增多，更多的開發人員加入到公司，發布代碼需求開始增多，這就占用了我大部分時間，經常的被打斷其它工作 來發布代碼，非常地不爽，然后開始想解決方法。
嘗試解決問題
當然，發布代碼肯定是運維的職責之一了，但頻繁的發布導致運維大部分時間浪費在重復的操作上，非常的不值得。基於此，開始限制代碼發布頻率，要求把 不是很緊急的更新延后到一周中的幾個時間點。但實施起來效果不理想，治標不治本，原因是你不能強制把需要立即上線的更改延后。實施這樣的定時發布，有可能 影響項目的快速迭代。
最終解決方案
想到這樣子下去也不是辦法，會造成工作很被動，於是開始着手建立以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命令來同步代碼到生產環境，這樣就實現了版本的回滾。
最后想說的話
最后想說的是，運維工作可以是枯燥的，也可以是有趣的。枯燥是因為沒有意識或者懶得把重復的操作通過制定流程來使其自動化，在不斷地把各種在運維工 作中占用時間比較多的重復操作通過技術來使得自動化時，我們既高效完成了工作，節省了時間，又能提高編程和解決問題的能力，只有這樣，我們才能讓運維工作 變得既有趣又有挑戰性。