上文中，由于初次接觸灰度發(fā)布，關(guān)于這一概念的踐行還有很多不了解的地方，因此標(biāo)題為“灰度發(fā)布用戶選取”。后來在進一步的了解中，逐步意識到，灰度發(fā)布不僅僅需要關(guān)注用戶群體，關(guān)于用戶特征、發(fā)布的方案、策略等等，其實有很多的方面需要細細考慮。因此灰度發(fā)布其實應(yīng)該有一個完整的方案。
灰度發(fā)布的方案，大致包括如下內(nèi)容：發(fā)布目標(biāo)、發(fā)布策略以及用戶篩選。
發(fā)布目標(biāo)可以有多個，如測試新功能以獲取用戶反饋、比較一個功能點兩個設(shè)計/實現(xiàn)方案的合理性/優(yōu)劣性（A/B測試）、推廣等多種目標(biāo)，一般而言選擇一個目標(biāo)即可，多選可能達不到既定的目標(biāo)。
發(fā)布策略，涉及到用戶規(guī)模、發(fā)布頻率、功能覆蓋度、回滾策略、運營策略、新舊系統(tǒng)部署策略。這里想提及一下當(dāng)前的項目需求--計劃建設(shè)一個通用的管理系統(tǒng)用于管理當(dāng)前的全部項目，其中部分項目有“灰度發(fā)布”的需求，上一篇文章中也曾提及想要選擇一個“普適”的方案，但是就發(fā)布策略而言，每個項目的特征決定了發(fā)布策略，因此難以做到“普適”的方案。但是由于當(dāng)前項目組的用戶范圍十分穩(wěn)定，“普適”的策略依然有一定的可行性，這一part還需要和開發(fā)團隊的小伙伴一起商量。如果“普適策略”可行，為了踐行項目的特征希望達到的差異性，可以在用戶篩選中選擇不同的用戶篩選方式--說到這里感覺自己已經(jīng)被說服了，美滋滋。
用戶篩選，希望新老用戶能夠同時參與（對于我們目前的項目而言，新用戶十分難以進行把控）。度娘上找到的灰度發(fā)布用戶篩選方案幾乎都是通過流量控制/渠道控制來實現(xiàn)，但是對于小型的互聯(lián)網(wǎng)應(yīng)用而言，流量/渠道其實十分單一，很難達到控制的效果。因此依據(jù)項目的特性，目前暫定以下方案：維護用戶列表并且增加“灰度”字段，項目需要使用灰度發(fā)布時，管理員通過隨機勾選or用戶設(shè)備編號最末位是數(shù)字且不小于5（按照項目的實施來決定用戶的占比，一定程度上實現(xiàn)新老用戶的同時參與）來實現(xiàn)用戶篩選。
目前的用戶規(guī)模：峰值為1200，日活在50-100之間；發(fā)布頻率暫時不穩(wěn)定，頻繁時期一周一次，非頻繁時期一月一次；不存在A/B測試，功能開發(fā)一般僅開發(fā)一個版本，因此功能覆蓋度可以有效掌控；回滾策略，由于低版本無法覆蓋高版本，擬將灰度測試的安裝包版本號加以字母“X”作為標(biāo)記，如需回滾，則將前一個版本的代碼作為新版本的資源并且標(biāo)記為回滾版本；新舊系統(tǒng)部署策略，暫時我了解到有兩種方案：發(fā)布一套后臺兼容新舊應(yīng)用，或者新舊后臺獨立部署，兩種部署方案目前我們會采用第一種方案。
今天暫時了解了這么多內(nèi)容，一邊記錄一邊幫助自己理清思路，美滋滋，最后的結(jié)論也出來了==