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%使用者，最後一天釋出到全量使用者。灰度期間發現嚴重問題時，可以暫停並重新提交一個新的版本，也可以在灰度過程中提前開啟全量。
這種灰度方案有兩個問題：
- 已經升級到灰度版本的使用者，無法回退；
- 無法精準選擇灰度使用者。
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，後續流程是一樣的。