iOS APP灰度發佈方案

灰度發佈解決什麼問題

對於大項移動APP來講，每一次版本的發佈，特別是在進行大的功能更新時，都須要選擇部分用戶先進行試用，並及時關注崩潰、卡頓、用戶反饋等，等待各項業務指標都達到預期要求時，才能將新版本全量推向市場。灰度發佈是移動產品穩定性的重要保障，它能解決如下問題：

• 常規測試的侷限性

常規測試很難覆蓋到足夠的機型，也沒法蒐集到足夠多的測試數據。一旦常規測試沒有發現一些隱蔽的致命bug，APP帶着bug上線，後果不堪設想。灰度發佈便是讓部分用戶參與到產品測試中來，一旦發現問題，可及時止損，將影響下降到最小。

• 驗證服務

高頻服務新上線時，客戶端和服務端都須要一個適應的過程，灰度發佈能逐步放量，保證服務可控。

• AB測試

新上線的功能，當沒法肯定哪一種方式更受用戶歡迎或能帶來更大的收益時，能夠採起AB測試。而AB測試用灰度發佈的方式再適合不過。

灰度策略

灰度發佈要達到比較好的效果，須要設計一套優秀的灰度系統。它應該具有或部分具有如下幾個特徵：

人羣篩選

灰度發佈通常是和具體業務相關聯的，業務需求可能會和用戶的位置、年齡、機型、標籤等相關，這就須要灰度系統在篩選灰度用戶時，可以根據特定的條件獲取最優的實驗樣本，以最短的時間獲取最有價值的數據。

數據反饋

除了監控APP的崩潰、卡頓等性能問題外，還須要關心灰度的業務指標。特別是對於AB測試來講，如何區分兩組測試哪一組更優，須要設計一個統一的計算方式。常見就是轉化率指標，在灰度的業務路徑中，應該事先進行數據埋點。

及時止損

灰度發佈雖然是一項測試行爲，但發生大範圍的崩潰或功能不可用問題，對用戶的使用體驗也是一種傷害。當出現問題時，應該能引導用戶回滾或更新到正常版本。

iOS的灰度方案

對於Android和Web產品來講，由於能夠自由的控制發佈渠道，因此灰度方案相對容易。但對於iOS APP來講，受限於AppStore，灰度方案比較單一。在早幾年91市場流行的時代，越獄用戶的佔比相對較高，有不少APP選擇在越獄市場進行灰度，但越獄市場的問題在於很難獲取有效的實驗樣本，灰度反饋的數據可能和實際狀況有誤差，如今已基本不採用。

目前，iOS的灰度主要有兩種方式：

Phased Release for Automatic Updates

在AppStoreConnect的後臺，能夠對APP進行分階段的自動更新。該灰度機制將灰度分爲七天，第一天發佈1%的用戶，次日發佈2%...第六天發佈50%用戶，最後一天發佈到全量用戶。灰度期間發現嚴重問題時，能夠暫停並從新提交一個新的版本，也能夠在灰度過程當中提早開啓全量。

這種灰度方案有兩個問題：

1. 已經升級到灰度版本的用戶，沒法回退；
2. 沒法精準選擇灰度用戶。

TestFlight

TestFlight測試工具容許開發者經過郵件等方式邀請用戶測試。TestFlight在被蘋果收購以後，和AppStoreConnect進行了深刻整合，如今，它能夠生成一個公開的連接，用戶能夠直接安裝測試。

內部測試

在AppStoreConnect後臺容許從開發者帳戶的開發、銷售、管理成員中邀請少許的（25個）內測用戶，內測用戶不須要審覈可直接安裝灰度版本的APP。很是適合內部在發版前進行總體功能的驗證測試。

外部測試

在AppStoreConnect後臺的TestFlight項新建並提交灰度版本審覈經過後（和正式版本的審覈不同），能夠生成基於TestFlight的公開連接，用戶訪問該連接後，便可安裝灰度版本的APP。

不少iOS APP使用「內測邀請」實際上就是依賴於TestFlight的「外部測試」的能力。當用戶打開現有版本的APP後，服務器能夠根據當前用戶的標籤判斷是否爲灰度用戶。若是是的話，需下發TestFlight的安裝連接，APP端引導用戶進入TestFlight安裝。外部測試有一些限制條件：

• 用戶需安裝TestFlight（內部測試也同樣）；
• 有效測試時間爲60天（內部測試也同樣），再有效期結束以前需引導用戶更新正式版本；
• 外部測試用戶能夠達到最多10000。

最佳實踐

• 已安裝TestFlight

可經過判斷itms-beta scheme的方式判斷用戶是否已經安裝TestFlight，若是用戶符合版本、機型、位置等維度的邏輯條件，則可彈窗提示用戶搶先體驗。用戶點擊接受體驗則跳轉至TestFlight安裝。用戶不接受體驗時，可回收邀請連接供其餘用戶使用。

• 未安裝TestFlight

這種狀況下若是用戶命中灰度條件，須要先引導用戶下載TestFlight，後續流程是同樣的。

原文地址：easeapi.com/blog/blog/1…