上線卡半夜、出 bug 只能硬扛？前端自動化部署 + 秒級回滾方案來了

點擊下方“JavaEdge”，選擇“設為星標”

第一時間關注技術干貨！

本文已收錄在Github，關注我，緊跟本系列專欄文章，咱們下篇再續！

• 魔都架構師 | 全網30W技術追隨者

• 大廠分布式系統/數據中臺實戰專家

• 主導交易系統百萬級流量調優 & 車聯網平臺架構

• AIGC應用開發先行者 | 區塊鏈落地實踐者

• 以技術驅動創新，我們的征途是改變世界！

• 實戰干貨：編程嚴選網

項目上線前最后一步，把開發好的代碼部署到線上。

“npm run build不就行”。這只是在本地把代碼打包，想在線上也可訪問這些代碼，還需部署。所以在下面，如今的前端代碼部署時的難點在哪呢？

1 部署難點 jQuery時代之前

前端項目中所有內容都是一些簡單的靜態資源。網站還沒部署的概念，網站上線前，直接把開發完的項目打包發給運維，再由運維把代碼直接上傳到服務器的網站根目錄下解壓縮，完成項目部署。

jQuery時代

項目的入口頁面被后端管理，模板部署到后端，CSS、js和圖片等靜態資源依然是打包到后端之后，再解壓處理。但現在，對前端的性能和穩定性的要求也越來越高，jQuery時代那種簡單部署模式不足以應對性能優化、持續部署。

當下主要面臨的代碼部署難點

• 咋高效地利用項目中的文件緩存

• 咋能讓整個項目的上線部署過程自動化，盡可能避免人力的介入，提高上線穩定性

• 項目上線之后，如果發現有重大Bug，要考慮咋盡快回滾代碼

當我們面對這些代碼部署上的難點，特別是在團隊協作的項目中遇到時，我們就可以考慮對項目進行自動化部署了，這樣代碼部署的速度和穩定性會給項目研發效率帶來很好的提升。

2 上線前的自動化部署

如下是大部分團隊部署項目時的邏輯：

完成打包壓縮，即開發完項目后，代碼推送到GitHub，就算完成任務。但打包代碼后，把代碼上傳服務器也是這步，對于前端開發者，很少能接觸，但卻很重要。

咋把打包好的代碼上傳服務器，需好的解決方案。

• 先需一臺獨立機器進行打包和構建，該機器需獨立于所有開發環境，為保證打包環境穩定

• 部署任務啟動的時候，需拉取遠程代碼，并切換到需部署的分支，然后鎖定Node版本進行依賴安裝、單元測試、ESLint等代碼檢查工作

• 最后，在這臺機器，執行經過編譯產出的打包后的代碼，并打包上傳代碼到CDN和靜態服務器

• 完成這些操作后，還要能通過腳本自動通過內部溝通軟件通知團隊項目構建的結果

項目部署過程可能遇到如下

問題

• 在什么os環境中執行項目的構建？

• 由誰觸發構建？

• 咋管理前面所述的把代碼上傳CDN時，CDN賬戶的權限？

• 咋自動化執行部署的全過程，若每次都由人工執行，就得消耗一個人力守著編譯打包，且易引發問題，如測試的步驟遺漏或部署順序出錯。咋提升構建速率，是部署功能中需解決的重要問題。

如采用能保證環境一致性的Docker；自動化構建觸發可通過GitHub Actions；GitHub的actions功能相當于給我們提供了一個免費的服務器，可以很方便地監控代碼的推送、安裝依賴、代碼編譯自動上傳到服務器。

這是用GitHub Actions部署項目后的項目開發流程。現在靜態資源管理已完成，也實現自動化部署。提交代碼后，項目就可自動推送到服務器，網站第一次上線成功。

3 上線后的自動化部署

后續的持續上線咋辦？直接發到生產環境，面臨極大風險。但不直接發布到生產環境，我們就不能在本地和測試的前端環境去連接生產環境的數據庫。

需預發布的（Pre）環境，只能讓測試和開發訪問，除了訪問地址的環節不同，其他所有環節都和生產環境一致，提供最真實的回歸測試環境。

又面臨

3.1 問題

若確定下周一零點發布，就只能晚上12點準時守在電腦前等結果？若npm安裝依賴失敗或上線后發現重大Bug，就只能迎投訴？

隨node_modules體積越來越大，構建時間越來越長。若每次構建都需30min甚至更長，即使Bug在項目剛上線時就發現，且秒級響應修復，但重新部署項目時，也要等服務器慢慢編譯。時間就是金錢，若你在修復Bug和重新部署項目上耗時長，就導致項目故障時間過長。

解決方案

需一種機制，讓我們發現問題后，盡快回滾版本，且在回滾過程，盡可能無需人力介入。所以，需靜態資源的版本管理，即讓每個歷史版本的資源都保留，且有唯一版本號，如故障，能瞬間切換版本。這個過程由具體代碼實現后，只需點擊回滾的版本號，系統就自動恢復到上線前版本。

該機制下，如業務流量特大，那直接全量上線的操作就會被禁止。為減少上線時，部署操作對用戶的影響，需先選擇一部分用戶做灰度測試，即上線后的項目的訪問權限，暫時只對這些用戶開放。或做AB測試，如給北京的同學推送Vue課，給上海推薦React課等。我們要做的，是把不同版本代碼分開打包，互不干涉。之后，再設計部署的機器和機房去適配不同用戶。

Gtihub中可用actions配置打包功能，下面的代碼是actions的配置文件。Ubuntu作服務器的打包環境，拉取GitHub最新master代碼，并把Node版本固定14.7.6，執行npm install后，再執行npm run build代碼打包壓縮。

通過GitHub Actions自動化打包一份準備上線的代碼：

name: 打包應用的actions
on:
push:# 監聽代碼時間
    branches:
      -master# master分支代碼推送的時候激活當前action
jobs:
build:
    # runs-on 操作系統
    runs-on:ubuntu-latest
    steps:
      -name:遷出代碼
        uses:actions/checkout@master
      # 安裝Node
      -name:安裝Node
        uses:actions/setup-node@v1
        with:
          node-version:14.7.6
      # 安裝依賴
      -name:安裝依賴
        run:npminstall
      # 打包
      -name:打包
        run:npmrunbuild

然后配置上線服務器和GitHub Actions服務器的信任關系，通過SSH密鑰可實現免登錄直接部署。直接把build后的代碼打包壓縮，通過SSH直接上傳到服務器，并且要進行代碼文件版本的管理，就完成代碼部署。

部署成功后的結果通知。釘釘、飛書都提供推送結果，可隨時通過群機器人接口把消息推送到群內，把版本號、部署日期、發起人等信息推送到對應接口，就完成自動化部署。

編程嚴選網：http://www.javaedge.cn/ 專注分享AI時代下軟件開發全場景最新最佳實踐~