本文介紹一種前端灰度發布方案，主要解決的是傳統的灰度發布只能以機器維度進行分組的問題。提供一種使用者維度分組的灰度發布機制。
傳統灰度發布，因為是以機器分組，所以要求服務是無狀態的。所謂無狀態就是對請求的處理是上下文無關的。有長連線、讀寫檔案、快取等場景，就是所謂」有狀態「的。有狀態的服務，如果使用者的前乙個請求打在機器a，後乙個請求打在機器b，就會出問題。
所以，有狀態的服務灰度發布，要做到：
同一使用者始終訪問同一版本的**
放量過程像傳統發布一樣可控
本灰度發布方案對構建、部署、啟動服務、處理請求階段分別做改造，實現有狀態服務灰度發布。
1、方案概述
我們把線上的**稱為stable版，本次發布的新**稱為beta版。先整體描述一下方案：
用git tag標識每次發布
在構建階段生成tag，同時用tag名稱來命名manifest.json
每次構建完新版本後，從cdn源機器取回上次發布的manifest.json檔案，一併放在dist目錄下
部署階段全量部署到所有機器，在執行階段來決定訪問哪個版本的**
node層啟動服務時，讀dist目錄下的兩份manifest.json檔案，這樣就能拿到新舊兩個版本的檔案清單
處理請求時，根據動態配置的放量資訊和分流策略，來決定使用哪個manifest.json中的檔案
版本號資訊放在cookie中，以保證同一使用者始終訪問同一版本**
2、開發階段
正常開發**，無需有任何額外操作。
3、構建階段
publish-tag
新增乙個git tag，以p-開頭，意為publish。每次發布都有乙個tag標記，格式為p-201911111001-lvdabao.標記發布時間與發布者。構建完成並同步cdn成功後，會將該tag同步到git倉庫。
manifest.json
manifest.json是webpack構建完畢後的檔案清單，可以用webpack-manifest-plugin外掛程式生成。如有特殊需求也可以自己編寫。我們是自己編寫，並在動態渲染首頁html時讀取清單內容並輸出script標籤。
每次構建生成的檔名稱是這樣的格式：manifest-p-201911111001-lvdabao.json，這樣每次發布都生成對應tag命名的manifest.json檔案。
啟動服務時可以一次讀取到記憶體中，並不是處理每個請求都讀一下檔案，所以不必擔心效能。
獲取上次發布的版本資訊
我們是用publish-tag來標識版本號的，只要拿到上次發布時的tag，就能取到對應的manifest.json檔案。所以構建的最後一步就是把上一版的manifest.json檔案從cdn源機器取到當前構建後的dist目錄下，為後續服務啟動時使用。
取上次的tag也很簡單，乙個git命令搞定：git tag –sort=-taggerdate | grep 「^p-.*」 | head -n 1
容錯機制
如果上次發布的版本有重大問題，不能作為stable版使用，有什麼辦法呢？
所以我們增加了乙個額外流程，允許構建的時候傳入環境變數，指定stable tag。這樣在獲取stable版本資訊時，優先取環境變數中指定的。
4、部署階段
部署跟普通流程沒什麼區別，將dist目錄發布到目標機器就行了。每次部署的dist檔案包含以下：
beta版的manifest.json檔案
beta版的資源檔案
stable版的manifest.json檔案
5、啟動服務
啟動服務時我們需要幹兩件事情：
把兩個manifest.json檔案讀到記憶體中，供分流時使用
自動修改放量配置，將新版本比例改為
git灰度發布版本 一種前端灰度發布方案
本文介紹一種前端灰度發布方案，主要解決的是傳統的灰度發布只能以機器維度進行分組的問題。提供一種使用者維度分組的灰度發布機制。傳統灰度發布，因為是以機器分組，所以要求服務是無狀態的。所謂無狀態就是對請求的處理是上下文無關的。有長連線 讀寫檔案 快取等場景，就是所謂 有狀態 的。有狀態的服務，如果使用者...
git灰度發布版本 Git發布2 30版本
git 2.30版本已於北京時間今天凌晨3點發布，是該廣受歡迎的分布式修訂版本控制系統的最新穩定版本更新，git由linux核心發明者linus大神於2005年推出。2020年早些時候，git 2.28版本帶來了對可配置 預設分支名稱的支援，以取代到目前為止的預設 master 分支名稱的用法。對於...
線上版本灰度發布策略
從接觸運維開始，最苦逼的事情就是業務上線，為什麼這麼說？就是因為有了很多的大坑隊友。不是因為開發的童鞋漏提 就是因為測試童鞋線下測試的不到位導致 扔到線上後出現各種問題，各種404。近期和各位童鞋研究了應對這種現象的解決方案，得到了如下結果 上線分為如下幾種等級 測試發布 預發布 灰度發布 正式發布...