前端路由服務及CI/CD流程

背景

公司各團隊管理本身的項目，分別有賣家中心、管理中心、商城、h五、...等項目。項目多達40+個。須要統一規劃配置項目對應的路由、構建後靜態資源存放地址。

前端頁面渲染過程

瀏覽器輸入url請求頁面，通過路由服務，根據路由配置去拉取OSS上相應的index.html

前端項目CI/CD、請求頁面到渲染，都會根據路由服務中的路由配置，結構以下：

[
   {
      "gitRepo": "cassfrontend/seller-merchant-react", // 項目倉庫地址
      "cdnRoot": "/www/seller/merchant", // 構建後項目CDN存放目錄
      "url": ["/seller/merchant"] // 瀏覽器請求的url
   },
   {
      "gitRepo": "cassfrontend/seller-test-react",
      "cdnRoot": "/www/seller/test",
      "url": ["/any/path", "/alias/path"]
   }
]

爲何路由服務在返回index.html以前須要改寫PUBLIC_PATH呢？

由於生產構建時設置靜態資源引用路徑是'./'，相對於當前路徑獲取靜態資源，根據上圖描述也就是https://ec-test.casstime.com/seller/merchant/目錄，可是/seller/merchant項目構建後存放的目錄是/seller/merchant/prod/，域名也不同，應該是OSS的域名https://mstatic.cassmall.com。所以，路須要改寫PUBLIC_PATH，向OSS請求靜態資源。

webpack支持動態PUBLIC_PATH，在項目主入口文件index.ts中引入import './public-path';

// public-path.ts

declare var __webpack_public_path__: string;

__webpack_public_path__ = (window as any).__PUBLIC_PATH as string;

export default __webpack_public_path__;

路由服務返回index.html，向其中注入script腳本設置window.__PUBLIC_PATH = "xxx"

<!-- index.html 處理前 -->
<script src="/js/main.54b2835a.chunk.js"></script>

<!-- index.html 處理後 -->
<script>
window.__PUBLIC_PATH = "https://mstatic.cassmall.com/admin/merchant/prod/"
</script>
<script src="https://mstatic.cassmall.com/admin/merchant/prod/js/main.54b2835a.chunk.js"></script>

頁面加載具體流程

部署及回滾方案

一、發佈前端項目時，採用非覆蓋式發佈。每次構建後，入口文件index.html 按版本號複製一份。CDN目錄結構以下：

/seller/merchant/prod
   css
   js/
       main.fade23.js
       main.aeb3ef.js
   index.html
   index-v2.0.0.html
   index-v1.0.0.html

二、每一個項目能夠配置惟一的目錄（cdnRoot），不一樣環境的靜態文件部署到cdnRoot對應的子目錄中。

環境	目錄
災備環境	${cdnRoot}/backup/
演示環境	${cdnRoot}/demo/
生產環境	${cdnRoot}/prod/
測試環境	${cdnRoot}/test/

三、構建/發佈示意圖以下:

四、須要回滾到指定版本時，只須要將對應版本的html重命名爲 index.html 便可快速回滾，回滾示意圖以下：

解決了哪些問題

• 路由服務業務邏輯簡單，但區分 admin、seller，須要爲每一個項目單獨編寫路由，配置複雜。
• 部署目錄不規範，項目多後很差管理
• 不一樣環境的公共路徑（publicPath）不一致，致使在不一樣的環境須要單獨構建。有可能存在測試環境和線上環境代碼不一致的問題。
• 構建和發佈在同一個流水線，存在外部環境影響構建結果的風險。
• 當回滾靜態資源時，須要從新構建。

Q&A

• 爲何忽略路由緩存

  內網獲取OSS頁面很是快（10ms內），並且頁面請求量不會特別高（單頁應用，應用內【項目內】切換頁面不會刷新），不必作太複雜的緩存，緩存只做爲容錯的補救措施。

• 爲何再也不構建時觸發更新

  這種操做加大CI複雜度，發佈的同時更新路由配置關係（Redis），系統變得複雜。路由服務但願像通常反向代理同樣，文件變化了，就給前端返回變化後的文件。文件自己的變化能夠經過 HTTP 304 機制優化。