企業級灰度發佈代碼上線詳述

什麼是灰度發佈：

---

灰度發佈（又名金絲雀發佈）是指在黑與白之間，可以平滑過渡的一種發佈方式。在其上能夠進行A/B testing，即讓一部分用戶繼續用產品特性A，一部分用戶開始用產品特性B，若是用戶對B沒有什麼反對意見，那麼逐步擴大範圍，把全部用戶都遷移到B上面來。灰度發佈能夠保證總體系統的穩定，在初始灰度的時候就能夠發現、調整問題，以保證其影響度。

---

什麼是灰度期：
灰度期：灰度發佈開始到結束期間的這一段時間，稱爲灰度期。

---

我所理解的灰度發佈：
簡單點說灰度發佈，以「測試服」與「正式服」爲例。先讓部分人先體驗，各方面（功能、用戶體驗等）都沒問題再擴大範圍。
灰度發佈的主要任務是從產品用戶羣中按照必定策略選取部分用戶，讓他們先行體驗新版本的應用，經過收集這部分用戶對新版本應用的顯式反饋（論壇、微博）或隱式反饋（應用自身統計數據），對新版本應用的功能、性能、穩定性等指標進行評判，進而決定繼續放大新版本投放範圍直至全量升級或回滾至老版本。****

---

灰度發佈系統須要考慮的一些要素：
（1）用戶標識
用於區分用戶，輔助數據統計，保證灰度發佈過程當中用戶體驗的連貫性（避免用戶在新舊版本中跳變，匿名Web應用比較容易有這個問題）。匿名Web應用可採用IP、Cookie等，需登陸的應用可直接採用應用的賬號體系。
（2）目標用戶選取策略
即選取哪些用戶先行體驗新版本，是強制升級仍是讓用戶自主選擇等。可考慮的因素不少，包括但不限於地理位置、用戶終端特性（如分辨率、性能）、用戶自身特色（性別、年齡、忠誠度等）。對於細微修改（如文案、少許控件位置調整）可直接強制升級，對於相似新浪微博改版這樣的大型升級，應讓用戶自主選擇，最好可以提供讓用戶自主回滾至舊版本的渠道。對於客戶端應用，能夠考慮相似Chrome的多channel升級策略，讓用戶自主選擇採用stable、beta、unstable channel的版本。在用戶有明確預期的狀況下自行承擔試用風險。
（3）數據反饋
用戶數據反饋：在獲得用戶容許的前提下，收集用戶的使用新版本應用的狀況。如客戶端性能、客戶端穩定性、使用次數、使用頻率等。用於與舊版本進行對比，決策後續是繼續擴大新版本投放範圍仍是回滾。服務端數據反饋：新版本服務端性能、服務端穩定性等，做用與用戶數據反饋相似。

（4）新版本回滾策略
當新版本灰度發佈表現不佳時，應回滾至舊版本。對於純粹的Web應用而言，回滾相對簡單。主要難點在於用戶數據的無縫切換。對於客戶端應用，若是期待用戶自行卸載新版本另行安裝舊版本，成本和流失率都過高。能夠考慮經過快速另行發佈新版本，利用升級來「回滾」，覆蓋上次灰度發佈的修改。對於移動客戶端，新版本發佈成本較高，須要Appstore、Market審覈。本人沒有移動客戶端產品的經驗，不太肯定移動客戶端產品如何處理灰度發佈及回滾。但儘可能將客戶端打形成Web App，會更有利於升級和回滾。（不過蘋果對純Web App類的App有較強的限制，好像已經不容許在Appstore上發佈這類應用了？）
（5）新版本公關運營支持
對於改版級別的大型升級，須要配合公關運營支持，用於及時處理用戶在微博、博客等渠道給出的「顯式反饋」。對比經過隱式數據反饋獲得的結論後，綜合考慮應對策略。

參考連接：https://www.zhihu.com/question/20584476/answer/15558660