本文僅供參考，可能仍然存在很多理解不深刻的地方
我先簡單的描述一下，釋出系統的一個發展歷程，純屬個人見解，請勿見笑
發展歷程：

• 第一代：手動部署，上傳程式碼到伺服器，然後修改配置，啟動伺服器等等 流程都差不多了 就封裝一個shell指令碼
• 第二代：web介面，既然都開始封裝指令碼了，是否需要有個介面，至少可以知道釋出的狀態，進度等資訊，如開源工具ControlTier（rundeck）
• 第三代：自動部署，已經規範部署流程，可持續整合部署，更多關注業務層面，一鍵部署，操作更簡單，配置更加複雜
• 第四代：雲部署，類似docker容器，整個程式碼、執行環境、作業系統全部打包進行拷貝部署

本文主要還是圍繞所謂的第三代進行講解，我主要用過的工具有

當然 我做過的兩個釋出系統都是 基於上述兩個工具 說白了 就是根據工具提供的API進行了二次封裝開發

這次封裝開發做了哪些事情？考慮的問題又有哪些了。。。請聽我慢慢道來

首先簡單談談封裝的東西：

大致的一個釋出流程是

1. 準備工作
   運維團隊可以定製釋出腳步，配置釋出的相關細節，如灰度釋出

2. 研發人員申請釋出
   建立釋出單 這裡最重要的就是版本號 版本的控制太多要講 下次開專題一起討論，如svn版本號，git版本號，war包版本號
   其實在這一步後面做的事情可多了，如對程式碼進行code review，編譯打包等等

3. 測試人員審批
   個人覺得在審批這一步，QA可以先發布程式碼到測試環境，經過一輪仔細測試，然後批准釋出

4. 部署
   一鍵式部署，點選部署按鈕這可以釋出

5. 檢測
   這是後臺程式做的一系列檢測，如流量是否正常

6. 回滾
   根據釋出的版本號，可以選擇性回滾到某一個版本，當然一般情況上，回滾到上一次釋出版本

其次考慮的問題：

灰度釋出：
灰度釋出是指在黑與白之間，能夠平滑過渡的一種釋出方式。AB 釋出就是一種灰度釋出方式，先對A組進行釋出，讓一部分使用者繼續用B，A組釋出完成後，一部分使用者開始用A，如果使用者對A沒有什麼反對意見，那麼逐步擴大範圍，將對B組進行釋出，把所有使用者都遷移到A上面來。灰度釋出可以保證整體系統的穩定，對使用者完全透明的升級，具備好的使用者體驗，在初始灰度的時候就可以發現、調整問題，以保證其影響度。
上面是copy過來的術語解釋，釋出系統引入灰度的概念，主要是為了提供友好的使用者體驗。同時也可以在生產環境上小測一會，這樣保證了線上環境的可靠性，這裡面我們又引入了一個概念，灰度暫停

灰度暫停:
大概意思是 假設把機器分為4組，啟用灰度暫停，則會發完一組，就好暫停後面3組釋出，當然沒有啟用，就會一組一組發完
我們當時考慮的灰度釋出，是針對每一個業務，每一個機房中灰度釋出

流量：
既然採用了灰度釋出，當然動態切除和恢復線上流量，將會是一個問題。為什麼會有流量這一說法？因為對於war包的釋出，大多數情況是需要重啟tomcat或resin伺服器的，當然php與python的部署，一般不需要。那我們是怎麼樣摘除流量的？其實就是簡單的修改nginx的upstrems配置

報警：
當時由於公司使用了zabbix監控系統，如tomcat掛了，所以我們在釋出前，事先遮蔽報警，那麼就可以幹壞事了。。。

容錯閥值：
為什麼要有這樣一個值？目前假設有100臺機器進行程式碼釋出，99臺釋出成功了，不能因為1臺機器釋出失敗，而認定此次釋出失敗，當然可以實現一些內部邏輯，去重試幾次，而有人會好奇，為什麼偏偏一臺釋出失敗，這樣子例子太多了，如硬體問題、手動上機器幹了壞事、網路波動等等原因

機房併發度：
這可能是我們國內特有的性質，一般會在多個機房部署同一套程式碼。所以我們引入了允許幾個機房同事進行釋出

機房並行度是否需要暫停：
當選擇允許暫停，則可以勾選釋出哪幾個機房，主要對於某些不穩定的版本，為了小範圍線上環境測試使用

機器併發度：
很重要的，直接影響到了釋出效率問題。這裡跟流量切換有直接的關係，這個併發度，是指灰度釋出中一組機器中，機器的並行釋出數
如100臺機器，分成4組，每組25臺，當然這裡我們配置的併發度最大為25，最小為1.假設配的是5，意思當釋出一組機器時，同時允許5臺機器釋出，配置為1就是序列釋出了，為什麼這樣做？為了保證釋出最小粒度，影響也最小，發現問題立馬回滾

通知機制：
最基本的，發郵件通知審批，釋出結束，釋出的結果等等

智慧排錯：
做到這一步就比較高上大了，簡單的說，就是在釋出的過程中，或出現各種各樣的錯誤，系統根據這些錯誤智慧解決，並進行釋出。
如某次上線，有同學上生產環境手動改了了程式碼，導致SVN釋出有衝突，系統可以自動解除conflict，然後進行釋出
在或者，部分機器程式碼釋出後，5XX狀態碼急速上升，智慧回滾的等等

智慧檢測：
怎麼樣去做好一個智慧檢測，確實是一個比較大的問題，牽涉到了系統的各方面的健康狀態？
我能想到的一些檢測工作：
1、伺服器是否啟動
2、程式碼中有檢測介面，請求該介面是否返回正常
3、版本號檢測，是否釋出正確的版本號

釋出模式：
由於公司業務決定，例舉一些我們的釋出模式，簡單講講
1、svn釋出，這種通常比較簡單直接svn更新到釋出的版本號
2、tomcat釋出，通常是war包釋出
3、resin釋出，類似tomcat
4、靜態資源釋出，zip包檔案推送解壓
5、nodejs釋出，包括了svn釋出與zip包釋出
6、git釋出，更加git的版本號釋出
7、php與python釋出 包含了svn、git、靜態資源釋出
8、定製化業務釋出

就寫到這裡了，寫多了，看不完，大家也懶得看，歡迎和大家交流