CICD自動化發版系統設計簡介

 第一篇。

版本迭代是每個互聯網公司必須經歷的，尤爲是中小型公司，相信很多人踩到過不少坑。接下來的一系列文章將介紹我設計的自動化發版系統！

不少公司沒有把配置獨立出去，代碼的構建、發版經過一個Jenkins job實現，我認爲這樣很很差。弊端以下：

• 若是你有N個環境，你將會有N次編譯、N次配置、產生N個包、發佈N次......；
• 配置變動困難，可讀性比較差；
• 版本發佈整體時間長等等。

事實上咱們須要： 

• 一次構建屢次發佈；
• 具有包倉庫，長期存儲並備份成品包；
• 具有配置管理系統，實現集中管理配置且維護簡單；
• 具有基本的回滾（備份）機制。

個人解決方案是：牢牢圍繞Jenkins+Gitlab+Ansible建設發版系統，經過Jenkins框架集成Gitlab、Ansible、sonar等第三方重要服務，同時引入配置管理系統（百度開源的Disconf），引入成品包倉庫（經過nginx+samba實現），再經過Ansible調度發佈及回滾腳本。

大體流程以下圖所示：

說明：

• Jenkins時刻監聽Gitlab代碼變化，當有研發人員向Gitlab提交代碼時，Jenkins會自動觸發構建、編譯並打包；
• 再經過shell腳本自動將打好的包上傳到成品包倉庫；
• 發版人員從成品包倉庫選取要發版的包上傳到Jenkins發佈job，執行一鍵發佈；
• 業務代碼在啓動過程當中會自動從Disconf系統中拉取配置完成配置併成功啓動。
• 整個流程看起來通俗易懂，但要注意一些關鍵點要具有提升可用性，好比：構建及發佈任務要作成集羣、要具有回滾機制等等。下面請看詳細的工做流程圖：

說明：

• 整個CICD最關鍵部分由Jenkins構成，Jenkins在這裏主要充當平臺做用，Jenkins由master/slave節點組成，master負責調度各個slave節點，真正幹活的是各個slave節點。在這裏，CI部分由2個jenkins slave節點組成，CD部分由2個Jenkins slave節點組成，CI與CD節點複用以高效利用資源；
• 當Gitlab有代碼變更時，Jenkins CI節點會自動觸發構建、編譯並打包，而後將打好的包自動上傳到成品包倉庫；
• 成品包倉庫主要由samba充當，發版人員能夠添加samba磁盤映射到本身電腦上，發版的時候能夠從samba倉庫上選取要發版的包上傳到Jenkins CD任務上；
• 一般測試環境與生產環境網絡是物理隔開的。若是要發版測試環境，則Jenkins會調用內網Ansible服務，Ansible調用相關發佈腳本實現發版，在發版過程當中，代碼服務會自動從測試環境Disconf下載並加載配置完成配置；同理，生產環境發版也是一樣的流程。

值得一提的是，這套發版系統在投入使用以前須要作一些標準化操做，好比：代碼包命名如何規範，CI/CD任務名稱如何規範，成品包倉庫中的包路徑如何定義,代碼配置如何獨立等等，免不了一些溝通協調。整體感受：自動化不難，「難的」是標準化的規劃及落地。

在稍後的幾篇文章中我將持續更新，努力將每一步都3D式的呈如今你們面前。

 

敬請期待～