前端自動化發布實戰總結
為什么要做
今年4月份，開始自己的第二份工作，習慣了老東家如絲般的發布體驗，一下子感覺來到了“原始社會”。
首先這是一篇長文，主要介紹自己在做自動發布這個過程的一些思考。
引用玉伯的Web研發模式演變來說，現在我們處于 - Web1.0時代：
- 前后端代碼耦合
- java環境對前端過于復雜
- 缺乏工具和規范，代碼難維護
- 內嵌代碼：html內嵌js，jsp內嵌java邏輯
- 頁面級代碼，代碼疊加：單文件js隨意2000行以上
- 人工手動發布，變更麻煩
遇到這種情況，首先會想到的肯定是前后端分離。但考慮到目前的人員、技術儲備情況，直接過渡到基于NodeJS的全棧式開發，阻力大，周期長，很可能會難產。
而我們首要要解決的問題是：
- 前后端職責清晰
- 提升開發效率、體驗
- 自動化發布
所以我們暫時先做到前后端物理分離，大致如 - Web2.0時代
- 代碼倉庫分離，分開維護
- 發布部署分離
- 模板由前端維護，在瀏覽器渲染，后端只提供基礎頁面容器（視情況而定）
- 交互性、非SEO頁面：后端負責接口，前端負責展現，通過接口讀取數據在瀏覽器端渲染
- 需要SEO的頁面：相關模板還是放在后端，但是會減少業務邏輯
目標
我們先從開發、發布流程來看我們最終希望的結果是什么，然后再分析如何完成這一目標
開發流程
- 項目遵循流程：需求評審 -> 視覺評審 -> 接口約定 -> 需求評估 -> TC評審 -> 并行獨立開發 -> 聯調 -> 測試 -> 發布
-
開發過程前后端明確任務，獨立并行開發
開發流程
發布流程
- 發布要嚴格遵守流程，測試審核通過才能上線
-
整個流程只需簡單發布指令，所有的編譯構建、同步服務器的事情交給任務去做（后面我們會提到發布任務需要做哪些事情）
發布流程
分離需要做什么
- 代碼分離
使用git來做代碼版本管理，申請新應用維護前端代碼 - 使用webpack，做模塊管理
代碼分離后，我們可以使用目前前端主流的框架、工具，搭建友好的開發環境、流程 - 分離之后，請求后端接口，聯調、debug，都需要設置代理
- 自動化發布
- 服務器配置
考慮如何部署前端代碼
自動化發布
首先聊一下一般發布的流程：
- 代碼提交
- 打包構建
- 備份服務器當前文件 - 回滾使用
- 將構建結果同步到服務器目錄
- 合并代碼到Master - 保證后續的代碼都是最新的
這是一些純體力活，要保證步驟順序和正確性，容易出問題，而且沒有記錄和日志，所以一般做權限控制，發布個普通需求還要找對應的同學發布，變更麻煩
所以發布必須自動化，網上搜前端自動化發布，大多數的結果都是Jenkins + githook （
Jenkins+github 前端自動化部署）
其核心原理主要是通過
- 提交代碼觸發webhook push event
- 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，這里就不贅述了
