隨著前端發展逐漸成熟，前端 CD 也隨著時間的遷移而變化。本文通過時間線的方式，簡述前端 CD 的過去、現在和將來。

part1: 純靜態頁面時代

1. nginx 反向代理訪問資源

前後端分離後，前端頁面變成了靜態資源頁面。只需要將頁面檔案部署在伺服器，再通過 nginx 反向代理，頁面就能被順利的訪問到。

2. 靜態資源替換進行更新

純靜態頁面的釋出，只需要將新的頁面資源把舊的資源替換掉，就完成了升級。

3. 使用虛擬系統遮蔽系統差異

為了遮蔽機器的操作細節，也為了更方便擴容，虛擬系統逐漸顯現。

因為系統裡面跑系統，佔用了更多的cpu、磁碟，這項技術一直沒被廣泛傳播。

5. docker 初現

此時 Docker + k8s(Kubernetes) 出現了，因為先前使用虛擬作業系統並沒有比較好的收益，這項技術在前端並沒有被廣泛使用。

part2: SSR 的現在

6. CSR 方式: 先請求資源，再請求資料

此時因為受到靜態資源載入後再發起請求，導致網頁初始化很慢，大家逐漸想起來前後端分離前的快樂。

7. SSR 方式: 一次請求，頁面開啟速度提升

前端開始逐漸往服務端渲染靠，開始逐漸做後臺的工作

8. SSR 方式: 消耗更多服務端資源

和靜態資源不同，服務端渲染會有一定程度上的資源消耗，就需要更多的機器了。

9. 是serverless 還是 docker + k8s?

需要操作機器更多，運維成本極限升高，開始尋求更低的運維成本。到底是serverless 還是 docker + k8s?

10. docker + k8s 能力強大，逐漸獲勝

中大型網站需要灰度能力，因此docker + k8s 在中大型前端中逐漸勝出。

part3: 釋出原子化的未來

11. 前端釋出速度快、多，如何減少釋出風險？

隨著釋出節奏緊鑼密鼓的進行，前端也受夠了線上反饋的問題，希望釋出系統能自動灰度；有問題可隨時會滾。

12. 釋出原子化，修改配置實現灰度、升級、回滾

通過 docker + k8s, 根據使用者id、IP進行自動灰度，能保證同一個使用者命中相同資源。每次釋出都會變成一次記錄，釋出和回滾只需要將域名流量切換，再也不需要提醒吊膽的釋出了。

結束語

資源替換、裸機 ssr 適合中小型的專案開發，釋出頻率不大；中大型前端追求釋出平穩，灰度簡單；每種形式各有優劣。本文以時間線的方式講述了前端 CD 發展的痛點和動機。

當然，前端 CD 還在逐漸發展中，還有很多技術需要不斷嘗試和更迭，僅是對現有的技術和最新的 CD 流程做簡述。

或許有一天開發者感知不到釋出。只需要定好釋出策略並隨時提程式碼呢？希望這天提早到來～

感謝您看到這裡～ 💗

創作不易，點個贊吧👍

也歡迎來我的部落格玩耍