前端自動化發佈實戰總結

爲何要作

今年4月份，開始本身的第二份工做，習慣了老東家如絲般的發佈體驗，一會兒感受來到了「原始社會」。 首先這是一篇長文，主要介紹本身在作自動發佈這個過程的一些思考。

引用玉伯的Web研發模式演變來講，如今咱們處於 - Web1.0時代：

• 先後端代碼耦合
• java環境對前端過於複雜
• 缺少工具和規範，代碼難維護
  • 內嵌代碼：html內嵌js，jsp內嵌java邏輯
  • 頁面級代碼，代碼疊加：單文件js隨意2000行以上
• 人工手動發佈，變動麻煩

遇到這種狀況，首先會想到的確定是先後端分離。但考慮到目前的人員、技術儲備狀況，直接過渡到基於NodeJS的全棧式開發，阻力大，週期長，極可能會難產。

而咱們首要要解決的問題是：

• 先後端職責清晰
• 提高開發效率、體驗
• 自動化發佈

因此咱們暫時先作到先後端物理分離，大體如 - Web2.0時代

• 代碼倉庫分離，分開維護
• 發佈部署分離
• 模板由前端維護，在瀏覽器渲染，後端只提供基礎頁面容器（視狀況而定）
  • 交互性、非SEO頁面：後端負責接口，前端負責展示，經過接口讀取數據在瀏覽器端渲染
  • 須要SEO的頁面：相關模板仍是放在後端，可是會減小業務邏輯

目標

咱們先從開發、發佈流程來看咱們最終但願的結果是什麼，而後再分析如何完成這一目標

開發流程

• 項目遵循流程：需求評審 -> 視覺評審 -> 接口約定 -> 需求評估 -> TC評審 -> 並行獨立開發 -> 聯調 -> 測試 -> 發佈
• 開發過程先後端明確任務，獨立並行開發

發佈流程

• 發佈要嚴格遵照流程，測試審覈經過才能上線
• 整個流程只需簡單發佈指令，全部的編譯構建、同步服務器的事情交給任務去作（後面咱們會提到發佈任務須要作哪些事情）

分離須要作什麼

1. 代碼分離 使用git來作代碼版本管理，申請新應用維護前端代碼
2. 使用webpack，作模塊管理 代碼分離後，咱們可使用目前前端主流的框架、工具，搭建友好的開發環境、流程
3. 分離以後，請求後端接口，聯調、debug，都須要設置代理
4. 自動化發佈
5. 服務器配置 考慮如何部署前端代碼

自動化發佈

首先聊一下通常發佈的流程：

1. 代碼提交
2. 打包構建
3. 備份服務器當前文件 - 回滾使用
4. 將構建結果同步到服務器目錄
5. 合併代碼到Master - 保證後續的代碼都是最新的

這是一些純體力活，要保證步驟順序和正確性，容易出問題，並且沒有記錄和日誌，因此通常作權限控制，發佈個普通需求還要找對應的同窗發佈，變動麻煩

因此發佈必須自動化，網上搜前端自動化發佈，大多數的結果都是Jenkins + githook （ Jenkins+github 前端自動化部署）

其核心原理主要是經過

1. 提交代碼觸發webhook push event
2. Jenkins監聽到webhook post請求，執行編寫好的腳本構建、同步服務器（主要依賴於腳本）

可是若是我想要查看發佈記錄、回滾、控制發佈流程，看起來Jenkins就幫不上忙了（可能有對應的插件，沒深究）

一樣的發佈腳本，用node也能執行，因此咱們打算使用node來寫一個發佈集成服務來代替Jenkins，它能夠作更細緻的控制：

• 提交代碼不表明發布，可能只是代碼備份，發佈指令才表明發佈
• 能夠生成發佈記錄，在發佈平臺展現，方便查看和回滾
• 實時反饋發佈流程信息
• 控制發佈流程，加入審覈、CodeReview，讓發佈更安全

因此咱們的發佈自動化主要作三個東西

• CLI：讓熟悉命令行的同窗，git push後立刻就能夠敲命令發佈（建立新發布、發佈）
• 發佈平臺：查看發佈記錄，發佈，審覈，查看日誌，回滾
• 集成發佈服務：執行發佈腳本，同步服務器，備份近期發佈文件（快速回滾），反饋發佈信息，發佈控制

CLI

該CLI是一套標準的前端開發生命週期命令，經過幾個子命令去完成前端開發流程的各個任務，包含了：

• init：初始化項目結構，相似於vue-cli init，不過比較入門簡單（由於暫時業務的體量並不須要頻繁建立新項目）
• dev：啓動開發調試服務，主要是npm run dev，也不是重點
• publish：發佈項目代碼，執行publish後將執行項目倉庫中對應開發分支下的代碼發佈任務。在雲端構建後的代碼最終會發布到對應的環境（SIT、UAT、生產）。

關於CLI的開發參考 - 如何用Node開發CLI 主要是：commander + inquirer

今後發佈就變成了一個命令的事

發佈平臺

發佈平臺提供了比CLI更多的功能：

• 查看發佈記錄
• 查看日誌
• 回滾
• 發佈管理、控制

集成發佈服務

到了重頭戲，這裏就介紹一些概念

發佈流程

爲何在雲端構建發佈

首先，最終代碼部署到服務器確定都是經過scp等命令來同步文件到服務器，由於權限問題，經過雲端統一管控是比較靠譜的。

而後，每一個人的機器環境都不同，有可能在A這構建成功，在B那卻構建失敗（好比A添加了一個依賴，但沒有保存dependencies），因此以統一的環境來編譯構建，能夠避免由於環境問題引發的構建問題。

最後，須要一個地方去統一管理髮布記錄，避免發佈衝突，記錄發佈日誌，方便回滾操做等。

分支管理

每一個人都基於Master拉取自定義分支開發，最終經過發佈自動同步到Master分支，保證開發時都是基於最新的線上代碼，同時發佈時作衝突檢查，保證發佈安全。

發佈過程的分支變化以下：

發佈管理

在整個發佈過程，咱們的代碼要經過平常、預發測試才能最終上線，這個過程是須要佔用對應服務器並保持穩定，須要避免出現其餘同窗發佈覆蓋的狀況，因此咱們使用MongoDB來維護發佈記錄，實現發佈控制和流程控制

發佈控制 當指定發佈環境有一個項目發佈時，該環境被佔用，其餘項目發佈會提示有其餘項目發佈，聯繫對應的發佈同窗，雙方根據重要性來決定是否退出發佈讓後來的項目先上

流程控制 爲了保證最終上線的代碼是正確運行的，整個過程須要測試和Code Review，必須經過測試、審覈才能進入下一個環節

發佈反饋

發佈腳本須要執行上面提到一系列的過程，這須要一個等待的過程，咱們須要實時給發佈同窗提供發佈反饋（發佈流程、成功與否），並將相關信息保存到日誌。因此發佈過程經過soket.io創建socket連接，集成發佈服務有任何流程變化都會反饋

同步服務器

同步服務器可使用 scp 或 rsync 命令，關於它們的介紹和不一樣看這個

這兩個命令經過ssh同步，都須要在執行命令後輸入密碼，因此須要配合expect來實現自動同步

最終整個服務選用了：express + socket.io + mongodb，這裏就不贅述了