主要參考了:
1、概述
所謂的灰度發佈,在行業內叫作A/B Test,因此能夠搜索一些這方面的關鍵詞
下面是某公司的灰度發佈流程,僅供參考。
一)經典總結1:
1)web頁面灰度。按照ip或者用戶id切流啊。具備隨機性,能夠控制比例
2)服務端灰度。考驗主系分能力了,能夠作邏輯切換開關,按照義務相關屬性逐漸切流
3)app。通常按照用戶逐漸推送包,主要是安卓。iso內部大規模內測
沒有不能灰度的業務,只有不能灰度的設計
做者:無名氣
連接:https://www.zhihu.com/question/28296375/answer/61894553
來源:知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權,非商業轉載請註明出處。
2)經典總結2:
web 區分區域、時間端、人羣作灰度
iOS 對比模塊同時存在,雲端控制模塊的關閉和開啓
Android,雲端控制升級彈窗
PC client 粉絲羣、論壇、不一樣的下發渠道作灰度
2、安卓很適合作灰度發佈
1)從服務器端下手
Android平臺作灰度再合適不過了。
找單一渠道投放特別版本出去是一個思路。另外一個是作升級平臺的改造,容許針對部分用戶推送升級通知甚至版本強制升級。web
不管哪一種方法都須要作好版本管理工做,分配特別的版本號以示區別。api
固然,既然是作灰度,數據監控(常規數據、新特性數據、主要業務數據)仍是要作到位,該打的數據樁要打。服務器
還有,灰度版最好有收回的能力,通常就是強制升級下一個正式版。
做者:張瑞
連接:https://www.zhihu.com/question/21714205/answer/19080164
來源:知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權,非商業轉載請註明出處。
2)從客戶端下手
本身作產品時也有相似的需求,下邊是個人方案:)app
基本的邏輯是兩個版本的代碼都打到app包裏,而後在app端植入測試框架,用來控制顯示哪一個版本。框架
測試框架負責與服務器端api通訊,由服務器端控制app上A/B版本的分佈,能夠實現指定的一組用戶看到A版本,其它用戶看到B版本。工具
服務端會有相應的報表來顯示A/B版本的數量和效果對比。測試
最後能夠由服務端的後臺來控制,所有用戶在線切換到A或者B版本~spa
因此這個也能夠用來作灰度發佈 :)設計
另外因爲打進去兩個版本的代碼,app的包體積會大一點(這和功能變化多少有關)orm
做者:且歌
連接:https://www.zhihu.com/question/21714205/answer/19080265
來源:知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權,非商業轉載請註明出處。
3)典型案例
MIUI的控制上,存在體驗版、開發版、正式版三個版本。
包括Chrome也有canary、dev、stable三個版本。
對於Android應用,可使用Google的分階段發佈。
Google開發者後臺能夠設置灰度發佈的百分比,5%,10%,20%,50%,100%。
4)應該有完善的工具能夠看到各類統計分析的數據,好比淘寶就有;
3、iOS版本很差作灰度發佈
iOS
上只能好好測試了,或者發佈越獄版本(但越獄版本有時候自己也是一種問題)
iOS比較麻煩,因爲審覈機制以及iOS自己對權限的控制,咱們一般是選擇越獄版本渠道來進行灰度,而後纔是正式版本灰度。
iOS:官方的測試平臺有Testflight,已經被蘋果收購,可是整個內測用戶邀請的方法流程仍是沒有打通,邀請用戶成本比較高,是經過添加用戶郵箱的方式,收到邀請郵件後還須要用戶按步驟下載tf,下載應用等,沒有一套教學視頻普通用戶仍是難以接受。但很是適合在新產品發佈前使用一些運營手段去創建這個用戶羣。用戶一旦完成第一次操做,之後更新就像appstore同樣簡單。對開發者來講,操做也是和appstore同樣的。比較方便。
且一個公司有多款產品的話,使用這個成本也會稍低一些,不過最大的問題仍是灰度的用戶量,和後期用戶的消亡管理和擴充
還有一個是若是有打不一樣的iOS渠道包(除了appstore還有其餘越獄渠道)或者其餘tag的話,也能夠經過升級配置來指定灰度發佈。
做者:AlwaysAT 連接:https://www.zhihu.com/question/28296375/answer/61898109 來源:知乎 著做權歸做者全部。商業轉載請聯繫做者得到受權,非商業轉載請註明出處。