由於工作需要，近期又惡補了一下 “灰度釋出”的相關知識，也和身邊小夥伴探討了輕量化實現 灰度釋出的落地方案。藉此機會，正好將相關內容跟大家整理分享一下。
什麼是灰度？
要想了解這個問題就要先明白什麼是灰度。灰度從字面意思理解就是存在於黑與白之間的一個平滑過渡的區域，所以說對於網際網路產品來說，上線和未上線就是黑與白之分，而實現未上線功能平穩過渡的一種方式就叫做灰度釋出。
灰度釋出又叫金絲雀釋出，起源是，礦井工人發現，金絲雀對瓦斯氣體很敏感，礦工會在下井之前，先放一隻金絲雀到井中，如果金絲雀不叫了，就代表瓦斯濃度高。
灰度釋出和 AB Test 的區別
和大部分人一樣，我個人之前對灰度釋出和 AB Test 存在一定的混淆，認為就是換了一種說法，但實際調研發現兩者之間存在著本質上的區別。
1、AB Test
AB測試一般由產品經理和運營來主導。它是把兩種功能，或者兩個版本，交給相同的使用者來使用，看使用者喜歡哪種功能。
要點是，AB的兩種功能都是可用的， 投放的使用者群體無差別，讓使用者選擇更受歡迎的功能，後期可能是A上線，也可能是B上線。
2、灰度釋出
灰度測試一般由研發，測試或運維來主導。它是把系統的新版本，或者說新功能，以部分上線的方法來上線，驗證新版本是否足夠可靠。
關鍵要點是，灰度版本未必是可用的，或者說沒有嚴重bug的，投放的客戶群體可能只是北上廣深等一線城市的使用者，由監控確定是否有問題，後續可能會繼續放量上線。
灰度釋出的優勢
1、提前獲得使用反饋，縮減風險影響範圍
因為灰度釋出可以透過地域、性別、使用者等級、使用客戶端等一系列的策略條件對目標使用者群進行篩選，所以可以保證驗證版本影響的使用者在最小可接受的範圍內。此外，基於驗證版本提前收集使用者使用意見，及時完善產品功能，並且根據使用者和監控的反饋結果，做到查漏補缺，對於過程中發現的重大問題，甚至可以及時的回滾至“舊版本”。
2、自定義規則引擎，精準控制內容投放
此外灰度釋出可以作為一個自定義的規則引擎，可按地域、人群、時段等自定義標籤對 App 模組或者 Web 頁面進行內容的精準投放，滿足企業產品的精準化投放釋出需要。就像是我們業務組負責人提出的需求，把新上線的活動僅投放給北上廣深四個一線城市的高等級使用者。
灰度釋出方案分析
1、TestFlight
對於 iOS 開發者來講有一個較為方便的灰度測試方案，也是大家使用最多的 —— TestFlight。TestFlight測試工具允許開發者透過郵件等方式邀請使用者測試。TestFlight 在被蘋果收購之後，和 AppStoreConnect 進行了深入整合，現在，它可以生成一個公開的連結，使用者可以直接安裝測試。
當使用者開啟現有版本的 App 後，伺服器可以根據當前使用者的標籤判斷是否為灰度使用者。如果是的話，需下發TestFlight 的安裝連結，App 端引導使用者進入TestFlight 安裝。
但 TestFlight 也有一定的不足：
- 使用者必須安裝 TestFlight ；
- 有效測試時間為60天，在有效期結束之前需引導使用者更新正式版本；
- 測試使用者可以達到最多10000。
2、功能小程式化
第二種對於很多開發者來講可能比較陌生，起因是因為公司的 App 較為臃腫，迭代發版非常麻煩，希望功能模組互相解耦實現模組化開發，各業務模組間互不影響，所以計劃整合 FinClip SDK ，讓整個 App 具備小程式的執行能力，繼而把 App 之前的業務功能都小程式化，透過管理後臺去實現動態更新與釋出。
剛好在進行技術體驗時發現， FinClip 的小程式是藉助部署的 FinClip 管理後臺實現上下架，上下架的同時可以進行上架規則的制定。這樣一來，相當於有了一個自定義的灰度釋出引擎去自由配置地域、性別、使用者等級等自定義條件，不需要編寫任何複雜的應用邏輯程式碼，完成上下架的同時就完成了精準的上線釋出。
相對於 TestFlight ，這種方式的優勢在於：
- 不僅可以用在iOS系統中，Android 和桌面端應用也能整合 FinClip SDK ，相當於灰度測試覆蓋的範圍更加廣；
- 自身的迭代升級，不會影響到宿主 App 執行的穩定性，也無需對 App 進行全迴歸測試；
- 小程式業務功能開發可以高度並行；
- 灰度釋出粒度更細緻（例如一個小程式是可以僅在測試白名單的範圍內試點）。
由於時間有限，我認為較好用的輕量化灰度釋出方案就暫時羅列這兩類，當然方案有千千萬，選擇自己合適的就好。