為什麼要做
今年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來實作自動同步原文釋出時間為：2018年06月16日
原文作者：okbeng03
本文來源：
https://juejin.im/post/5b23f18b6fb9a00e6433536d 掘金 https://juejin.im/entry/5b3a29f95188256228041f46如需轉載請聯系原作者