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

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

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

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

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

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

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

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

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

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

在發布頁面， 同時還可以看到上次發布的情況，已經發布每個階段的情況。

業務方人員還可以在統計分析頁面查看自己的發布情況，包括發布時間，發布次數，成功率等等。

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

7. 小結
發布系統馬上要接入公司的所有業務線，這對我們來說是一個不小的挑戰，如何優化我們的系統，提高系統的穩定性，如何讓用戶體驗更好，滿足更多需求,我們還有很長的路要走。