IT工程師數位筆記本

Android平臺做灰度再合適不過了。
找單一渠道投放特別版本出去是一個思路。另一個是做升級平臺的改造，允許針對部分用戶推送升級通知甚至版本強制升級。

無論哪種方法都需要做好版本管理工作，分配特別的版本號以示區別。

當然，既然是做灰度，數據監控（常規數據、新特性數據、主要業務數據）還是要做到位，該打的數據樁要打。

自己做產品時也有類似的需求，下邊是我的方案:)

基本的邏輯是兩個版本的代碼都打到app包里，然后在app端植入測試框架，用來控制顯示哪個版本。

測試框架負責與服務器端api通信，由服務器端控制app上A/B版本的分布，可以實現指定的一組用戶看到A版本，其它用戶看到B版本。

服務端會有相應的報表來顯示A/B版本的數量和效果對比。

最后可以由服務端的后臺來控制，全部用戶在線切換到A或者B版本~

所以這個也可以用來做灰度發布 :)

另外由于打進去兩個版本的代碼，app的包體積會大一點(這和功能變化多少有關)

    iOS：官方的測試平臺有Testflight，已經被蘋果收購，但是整個內測用戶邀請的方法流程還是沒有打通，邀請用戶成本比較高，是通過添加用戶郵箱的方式，收到邀請郵件后還需要用戶按步驟下載tf，下載應用等，沒有一套教學視頻普通用戶還是難以接受。但非常適合在新產品發布前使用一些運營手段去建立這個用戶群。用戶一旦完成第一次操作，以后更新就像appstore一樣簡單。對開發者來說，操作也是和appstore一樣的。比較方便。
且一個公司有多款產品的話，使用這個成本也會稍低一些，不過最大的問題還是灰度的用戶量，和后期用戶的消亡管理和擴充

還有一個是如果有打不同的iOS渠道包（除了appstore還有其他越獄渠道）或者其他tag的話，也可以通過升級配置來指定灰度發布。