這裡所說的自動化部署系統，其實是一種半自動的程式碼部署，不同於jenkins的持續整合，也不同於puppet,ansible的自動部署。根據公司實際情況，而定製的一種自動化部署方案:

背景介紹

公司專案釋出過程如下：

1. 開發人員上傳war包至svn目錄，併發郵件告知運維其svn目錄；

2. 運維人員從svn地址下載war包至本地；

3. 運維人員ssh2登陸遠端伺服器：

   • 備份服務war包
   • 停止服務
   • 上傳新war至相應的目錄
   • 啟動服務
   • 檢視log

方案設計

為了解決線下的手動部署，主要提供如下功能：

1. 開發人員部署申請

   關於svn檔案的上傳，暫時仍沿用，後期可以更換成web上傳功能進行替換。

2. 服務部署管理

   運維人員管理每個服務部署的情況，即哪個服務部署在哪臺伺服器的哪個目錄上；

3. 伺服器管理

   伺服器的管理，即每臺服務的ip地址，及ssh登陸所需使用者名稱、密碼;

4. 部署申請稽核
   運維人員稽核開發人員的部署申請，是否允許上線。

5. 自動化部署

   如何進行自動化部署，這是個難點？採用什麼技術，也是因人而異.比如ansible就採用python,而java web提代的自動化部署也有ant,tomcat deploy等。在這裡選擇通過ssh2登陸遠端伺服器，執行服務指令碼完成自動部署的操作。
   自動部署功能通過監聽部署申請稽核通過的訊息，進行自動化部署，主要進行如下操作:

   • 獲取部署申請資訊；
   • 根據服務的部署申請資訊，獲取服務的部署資訊；
   • 根據服務的部署資訊，獲取服務的物理伺服器資訊；
   • 根據部署申請資訊，從遠端svn地址下載war包至本伺服器的臨時目錄;
   • 通過ssh2登陸遠端伺服器，執行如下操作;
   • 備份服務war包;
   • 停止服務;
   • 上傳新war包;
   • 啟動服務;
   • 關閉遠端連線;
   • 刪除本地war包;

   因為我們後端的服務框架採用dubbox,所有服務都是多節點部署，所以顯示的停止服務在低谷請求是允許的。具體的專案程式碼請參見auto-deploy
   目前只完成自動化部署的核心功能，後續功能會慢慢補上。