pushguide發(fā)布系統(tǒng)，是汽車之家正在使用的代碼發(fā)布系統(tǒng)。「代碼上線」是運維日常工作中最重要的一部分。在沒有發(fā)布系統(tǒng)之前， 所有的業(yè)務都需要運維來手動上線。 上線工作對運維人員來說是不小的工作量。 為了解放生產(chǎn)力，提高上線效率，我們開發(fā)了該系統(tǒng)。

1. 背景
（1）野蠻生長階段
業(yè)務線自己各自為戰(zhàn)，沒有統(tǒng)一的代碼規(guī)范， 發(fā)布流程。 上線之前提交上線單通知運維人員手動上線。這種模式的缺點不言而喻，運維人員需要隨時待命， 從上線部署到最后驗證， 有問題的話回滾都需要運維人員全程手動完成，費事費力。
（2）統(tǒng)一規(guī)范，使用發(fā)布系統(tǒng)發(fā)布
業(yè)務線接入CI和發(fā)布系統(tǒng)之后， 業(yè)務方通過CI打包自己的代碼， 通過發(fā)布系統(tǒng)自助完成發(fā)布。如發(fā)布代碼有問題，可以在系統(tǒng)上直接選擇要回滾的版本。 運維人員只需要配置好要發(fā)布的模塊即可。大大解放了運維的工作量。同時，各個業(yè)務線需要按照統(tǒng)一規(guī)范組織自己代碼結(jié)構才能夠使用發(fā)布系統(tǒng)。

2. 設計原則
什么樣的系統(tǒng)更適合于汽車之家的業(yè)務？ 首要要滿足不同業(yè)務線的不同項目類型的發(fā)布，這些類型包括.net項目、java web項目、windows計劃任務等。 其次，公司有大量的windows服務器， 發(fā)布系統(tǒng)需要同時支持windows和linux。最終我們選擇基于saltstack自動化運維配置工具設計開發(fā)發(fā)布系統(tǒng)， 使用該工具的好處如下：
（1）python開發(fā)，和運維開發(fā)的技術棧一致。對于以后的擴展，二次開發(fā)都很方便
（2）快速, 原生提供了http api支持
（3）支持windows

3. 發(fā)布系統(tǒng)架構
3.1 發(fā)布系統(tǒng)的整體架構
發(fā)布系統(tǒng)前端通過salt api與salt master進行通信， 發(fā)布任務描述信息到salt master。salt master通過salt命令調(diào)用我們自己開發(fā)的模塊來完成一次發(fā)布任務。

3.2 發(fā)布系統(tǒng)與其他系統(tǒng)如何合作完成代碼發(fā)布
我們需要通過CI系統(tǒng)來打包代碼，通過配管系統(tǒng)來部署代碼運行環(huán)境，如tomcat等等。通過CI以及配管系統(tǒng)提供的接口，我們在發(fā)布系統(tǒng)中獲取到發(fā)布的版本和配置的tomcat信息

3.3 發(fā)布系統(tǒng)對上線流程的抽象
我們把一次上線流程抽象成以下四個階段
（1）準備階段
（2）發(fā)布前階段
（3）發(fā)布階段
（4）發(fā)布后階段
為了支持不同發(fā)布類型和可擴展性， 我們通過繼承抽象出不同的類來完成一次上線流程，如下所示：

4. 遇到的問題
作為重要的代碼發(fā)布系統(tǒng)， 穩(wěn)定性上一定要有可靠的保證， 這樣才能讓業(yè)務方人員放心大膽的使用系統(tǒng)發(fā)布代碼。但是在發(fā)布系統(tǒng)的使用過程中我們也遇到了一些問題。
4.1 確保salt的穩(wěn)定性
由于pushguide是基于saltstack來完成代碼的發(fā)布，所以對saltstack的運維又顯得很重要。在前期的使用的我們經(jīng)常遇到由于salt的問題導致發(fā)布系統(tǒng)出現(xiàn)不可用的情況。所以我們優(yōu)化了整個salt的架構。通過使用多機房multi master來保證salt的穩(wěn)定性。關于salt的高可用方案，網(wǎng)絡上也有一些其他做法如加入代理層，重寫returner模塊等方法。但從效果看，目前的multi master可以滿足我們現(xiàn)在的發(fā)布需求。
4.2 代碼的規(guī)范
系統(tǒng)使用前期，由于業(yè)務方的代碼不夠規(guī)范，比如我們在現(xiàn)實場景中會遇到有的業(yè)務方把業(yè)務代碼和日志文件放在一起，代碼目錄非常大，導致發(fā)布的失敗。所以對于發(fā)布系統(tǒng)的來說，我們不能僅僅是發(fā)布代碼， 同時可以制定代碼，目錄規(guī)范來約束業(yè)務方規(guī)范自己的代碼。
4.3 監(jiān)控
對于發(fā)布系統(tǒng)web服務的監(jiān)控自然是必不可少的， 同時我們還定時對接入發(fā)布系統(tǒng)的主機salt minion連通性進行檢測， 發(fā)現(xiàn)有salt minion不可用情況及時處理， 避免在發(fā)布時失敗的情況

5. 發(fā)布案例
下面以一次代碼發(fā)布為例， 詳細介紹發(fā)布系統(tǒng)的使用。
運維人員登錄發(fā)布系統(tǒng)，會根據(jù)權限展示運維人員可以看到的發(fā)布模板。

進入新建模板頁面， 填寫必要信息， 新建模塊。在模板類型選擇中可以選擇本次配置的是.net、java、windowd計劃任務等。

配置完成后，如果業(yè)務方有上線， 只要進入發(fā)布頁面，選擇要發(fā)布的版本，點擊發(fā)布，就可以自助的發(fā)布代碼。

在發(fā)布頁面， 同時還可以看到上次發(fā)布的情況，已經(jīng)發(fā)布每個階段的情況。

業(yè)務方人員還可以在統(tǒng)計分析頁面查看自己的發(fā)布情況，包括發(fā)布時間，發(fā)布次數(shù)，成功率等等。

6. 未來可以做的事
6.1 異步發(fā)布
目前發(fā)布系統(tǒng)的做法是同步發(fā)布， 點完發(fā)布后，頁面會阻塞在當前。 未來我們把整個發(fā)布過程異構， 使整個發(fā)布過程的體驗更加穩(wěn)定，流暢。
6.2 自動回滾
我們可以為讓業(yè)務方人員選擇是否自動回滾以及要回滾到的版本。 當發(fā)布失敗時， 執(zhí)行自動回滾邏輯， 讓發(fā)布更加輕松智能。
6.3 對發(fā)布數(shù)據(jù)的應用
通過統(tǒng)計業(yè)務方的發(fā)布情況， 我們可以規(guī)范業(yè)務方的發(fā)布行為。比如哪些時間段的發(fā)布成功率低，那些服務器總是發(fā)布失敗等等情況。通過這些數(shù)據(jù)分析， 幫助業(yè)務方提高上線的成功率和發(fā)布質(zhì)量。
6.4 可視化發(fā)布
以后我們可以做到上線的每個階段可視， 比如用流程圖展示出發(fā)布在哪個階段出了問題， 可以直接在該階段選擇是否回滾或其他操作等。

7. 小結(jié)
發(fā)布系統(tǒng)馬上要接入公司的所有業(yè)務線，這對我們來說是一個不小的挑戰(zhàn)，如何優(yōu)化我們的系統(tǒng)，提高系統(tǒng)的穩(wěn)定性，如何讓用戶體驗更好，滿足更多需求,我們還有很長的路要走。