關於前端項目部署發佈的相關思考

公司前端項目部署現狀

將 html 託管給後端，前端只發靜態資源（index.js/index.css），而後經過某種方式去刷 html 的靜態資源版本號（?version=時間戳或遞增數字）。

比較好的實踐

咱們先來看看前端項目部署的比較好實踐是什麼？

出處：大公司裏怎樣開發和部署前端代碼？

能夠總結出如下四點：

1. 配置超長時間的本地緩存 —— 節省帶寬，提升性能
2. 採用內容摘要做爲緩存更新依據 —— 精確的緩存控制
3. 靜態資源 CDN 部署 —— 優化網絡請求
4. 變動資源發佈路徑實現非覆蓋式發佈 —— 平滑升級

上面文章但是本文的基石，5 年過去了，更好的方案是什麼呢，還但願大佬賜教。

做爲一個畢業 1 年的菜鳥，我就先着上面的文章來看看目前公司發佈流程的不足吧。

公司部署方案優缺點

前端只發布靜態資源，只要 html 引用的資源不刷版本號，對老用戶是沒有影響的（存在強緩存，直接請求本地緩存，對應實踐 1），新用戶雖然沒有緩存，但因爲是靜態資源是同名覆蓋發佈，因此請求新的 index.js/index.css 資源，只要資源不依賴 html 結構，看到新版本功能，也沒有影響（注意：若是依賴 html 結構，請求新資源可能就會出現問題，好在目前單頁應用基本不依賴 html 結構，一個#root 根節點 就夠了）。

（強行）優勢

1. 覆蓋發佈。服務器不會有大量靜態資源文件積累。（這個很重要？）
2. 後端能夠向 HTML 內注入一些內容，好比用戶信息。

缺點

1. 粗粒度的版本號刷新策略，致使根據文件內容變化選擇性更新緩存（對應實踐 2）沒法實施
2. 覆蓋發佈。在 html 刷新版本號前，新用戶和老用戶可能看到的頁面版本（功能）不一樣
3. html 託管在後端，致使必定程度的先後端未分離（譬如打包策略變動須要後端配合更改 html）

照貓畫虎

那麼按照上面的實踐，如何處理比較好呢？

1. 前端每次基於 content hash（依賴數據摘要算法） 打包生成靜態資源文件名(例如 aaa.[contenthash].js 與 bbb.[contenthash].css)，文件名是否變化取決於文件內容是否變化
2. 使用前端的 html，前端可在打包過程當中自動注入靜態資源文件地址
3. 靜態資源先發布，html 後發佈

再來看看上面的缺點是否被解決了？

1. 粗粒度的版本號刷新策略，致使根據文件內容變化選擇性更新緩存（對應實踐 2）沒法實施

文件名是基於 content hash生成，在發佈新的 html 後，若文件內容未發生變化，文件名不會發生改變，依舊使用本地強緩存，若文件內容變化，文件名會發生改變，會請求新的靜態資源，達到了選擇性更新緩存的效果。

2. 覆蓋發佈。在 html 刷新版本號前，新用戶和老用戶可能看到的頁面版本（功能）不一樣

非覆蓋式發佈，文件名[contenthash]不一樣不會覆蓋，舊的靜態資源文件依舊存在。

新的靜態資源發佈後，新的 html 未發佈前這個時間段內，老用戶請求到舊的 html，請求的是舊的靜態資源，文件名(或者說文件路徑)未變化，依舊使用本地強緩存，新用戶請求到舊的 html，沒有本地緩存，但舊的靜態資源未被覆蓋，依舊能夠請求到，此時看到的都是舊版本內容。

新的 html 發佈後，老用戶瀏覽器會選擇性更新本地緩存，新用戶直接請求新的靜態資源，看到的都是新版本內容。

3. html 託管在後端，致使必定程度的先後端未分離（譬如打包策略變動須要後端配合更改 html）

html 徹底由前端控制，後端只須要提供 API 便可，先後端真正意義上的徹底分離。

缺點：

• 發生變化的文件 hash 值不一樣，非覆蓋發佈，可能形成服務器上無用的靜態資源愈來愈多，但這是能夠解決的
• 後端不能往 html 注入一些內容

結語

經驗淺了些，參考的資料古老了些，可能有些地方有失偏頗，請必定要指正。

並且項目上線是確定要配 Nginx 的，要去找運維幫忙配，流程上還有能夠優化的地方，如今這種形式對前端制約太大了。