得物 App 灰度 - 全量發佈效率提升實踐

目錄

一、背景

二、量化數據

    1. 版本報告

    2. 季度報告

三、優化方向

四、調整發布節奏

五、雙端提升發佈系統自動化能力

    1. 自動創建發佈計劃

    2. 打包 / 灰度 / 全量前卡口

    3.App 打包前置依賴提醒

    4. 自動打包

    5. 測試迴歸催收

    6. 事件訂閱

    7.Android 應用市場上架監控

    8.iOS 定製化蘋果商店

六、總結

一

背景

得物的發佈採用固定的雙週迭代，在此基礎上如有緊急的需求可以申請中間插入單週迭代版本，在以往的迭代發佈過程中從開始準備灰度發佈事宜到主要應用市場上架時間跨度較長，站在業務的角度像 AB、埋點、新特性反饋的時間太長。

最近我們針對發佈流程做了整個鏈路的優化，通過調整發布節奏、提升雙端發佈系統自動化能力等措施，幫助業務觸達用戶效率 (每版本提前 1 天)，下文將詳細講述此過程。

二

量化數據

發佈過程中涉及的不同職能的業務域較多，信息不透明、無法從全局視角瞭解整體發佈情況，因此想要做優化首先需要量化發佈數據，主要的作用包括如下：

1. 實時監控：幫助團隊實時監控灰度發佈的進度和效果。通過數據分析，可以瞭解不同版本在不同階段的表現，及時發現並解決問題，確保發佈過程順利進行。

2. 效果評估：可以評估不同灰度發佈策略的效果。比如可以根據數據分析結果調整灰度量、時間等參數，以提高發布效率和質量。

3. 問題診斷：幫助團隊快速診斷和定位發佈過程中出現的問題。通過數據分析，可以找出導致問題的原因，有針對性地進行修復和優化。

4. 持續優化：通過不斷積累和分析發佈數據，團隊可以發現發佈過程中的潛在改進空間，持續優化發佈流程和策略。量化數據的作用在於指導團隊進行持續改進，提升灰度發佈效率和成功率。

綜上所述，量化發佈數據在灰度發佈效率提升項目中扮演着至關重要的角色，可以幫助團隊監控、評估、診斷和優化發佈過程，從而實現更高效的灰度發佈。

我們對灰度的理解是用時間來換取減少潛在問題造成的影響面，好的質量意味着較少的灰度時間，反之效率的提升也能爲應對潛在的質量問題提供更多的時間 buffer，因此量化數據圍繞着 “質量”、“效率” 兩個關鍵字展開，每個迭代記錄各階段細化到具體的業務域的關鍵時間點、異常事件等，以版本報告、季度報告的形式呈現出來。

版本報告

以質量和時效兩個維度記錄迭代發佈過程中的重要時間點、異常事件，比如服務端各域發佈時間、客戶端各業務域代碼集成時間、App 構建時間、測試可開始迴歸 / 迴歸結束時間、灰度時間段 / 人數 / 質量情況、灰度因質量問題造成的熔斷、應用市場開始上架 / 審覈通過時間、應用市場拒審事件。

1. 質量

灰度對用戶產生的影響有彈窗、安裝、崩潰，我們主要關注了後兩個，分別使用灰度覆蓋人數 (此版本累計安裝的設備數)、bug 影響人數(累計崩潰的設備數) 來衡量。

2. 時效

業務迭代版本 (首個小版本) 是整個迭代發佈任務中最複雜的，依賴於服務端發佈完成、客戶端所有業務組件集成完畢、QA 完成全量的測試迴歸，因此需要重點關注，後續的版本主要關注上次灰度的問題修復時效，最終關注應用市場的上架情況(Android 關注華爲、小米、vivo、oppo 四大應用市場)；服務端發佈和客戶端集成組件用固定的時間來衡量，QA 測試迴歸有前置依賴使用可開始測試時間 + 固定的時長來衡量，上架使用 App 全量時間到應用市場審覈通過來衡量。

2.1 Android

2.2 iOS

區別於 Android 可以使用彈窗提示脫離應用市場進行灰度，iOS testflight 灰度名額較少，主要依賴蘋果審覈通過後通過逐步放量來發現問題。

圖片

名詞解釋

• 灰度時間: Android: 在發佈系統上操作開始灰度時間 (老版本用戶可展示升級彈窗提示的時間),iOS: AppStore 審覈通過後操作開始放量 1% 的時間。

• 提供測試包時間: 提供給測試用作迴歸功能的包出包時間。

• 測試可開始測試迴歸時間: MAX(服務端發佈完成時間，客戶端提供測試包時間)（QA 依賴服務端功能發佈完成和客戶端提供灰度包）

季度報告

季度報告是對本季度版本報告數據的縱向整合，主要關注各個關鍵指標優劣化情況和各個團隊在灰度發佈中的表現情況。

1. 灰度影響

2. 安裝

• 版本趨勢

每個迭代安裝量分佈、累計安裝量

• 季度彙總 & 各團隊表現情況

季度總共發佈了多少個灰度版本以及灰度覆蓋人數，以及歸因到每個業務域的數據，與上個季度相比的優劣化情況以及具體原因。

異常發佈: 正常情況下，一灰髮現問題，二灰驗證修復情況，二灰和全量版本之間的版本視爲異常發佈。

• 灰度輪次安裝量分佈

對比各輪次安裝量情況，是否有異常偏高情況，另外體現異常發佈導致的安裝量。

3. 崩潰

季度總共以及各業務域在灰度期間崩潰的設備數、與上個季度相比的優劣化情況以及具體原因：

一灰歸屬: 公共輪次（計入公共）。

二灰歸屬: 業務域所屬問題累計崩潰設備數 >=30%（如無必修則視爲公共 bugfix 驗證輪次，計入公共），其它灰度版本歸屬: 開版問題所屬業務域。

• 版本趨勢

每個迭代 Crash 分佈、累計 Crash 影響用戶數。

• 各團隊表現情況

  彙總這個季度內每個業務域所屬問題在灰度期間所有崩潰的設備數，與上個季度相比的優劣化情況。

• 灰度輪次 Crash 對比

  對比各輪次 Crash 影響用戶數分佈情況，一灰後佔比低說明一灰問題修復情況較好。

4. 時效

• 各職能域累計影響時長對比

體現服務端、客戶端、測試累計影響時長分佈情況。

5. 服務端

• 版本趨勢

以固定時間發佈完成爲目標，整體延期趨勢。

不同業務域在每個版本的發佈表現。

• 各團隊表現情況

  對比不同域在這個季度累計的延期時長，以及相鄰季度的優劣化情況。

6. 客戶端

• 提測延期版本趨勢

以固定時間完成出包提測爲目標的版本延期趨勢。

。

• 各團隊表現情況

  業務域組件集成延期，對產生兩種類型的影響，第一種: 尚未提測會導致 App 打包延期而導致提測延期，第二種: 如果測試提出的問題修復過晚，會影響到灰度。

7. 測試迴歸

• 版本趨勢

以 3h 完成測試迴歸爲目標整體完成情況，迴歸延期會產生客戶端問題修復延期、灰度延期的風險。

• 各團隊表現情況

8. 全量版本發佈

• 發佈類型分佈對比

• 版本趨勢

  每個迭代發佈全量版本數。

9. 友商發佈

橫向對比各友商季度累計上架的版本數，分析友商發佈情況以及得物 App 所處的位置。

• 季度對比

• 全年的對比

iOS AppStrore 審覈

• 版本趨勢: 每個版本蘋果審覈花費的時長

三

優化方向

通過對一個季度的數據進行量化分析，識別出了各子任務的依賴關係和並行情況以及關鍵卡點，逐步揭示了灰度發佈過程中的問題，併爲後續優化提供了明確的指引，主要有如下幾個方面：

• 各團隊灰度節奏不一致:  服務端發佈、客戶端代碼集成、測試迴歸等這些同類型的任務中，不同業務域節奏不一致。

  爲同類型任務劃定出一個明確的完成時間點，使同類型的任務儘可能的並行進行，例如爲服務端發佈完成和提供測試包時間約定一個相同的時間點完成，QA 測試迴歸有前面兩者的依賴約定好固定的完成時長，較大週期的任務時間點確認好了以後，在細化子任務的時間點，例如提供測試包需依賴客戶端業務組件集成完成、App 構建 task 完成，進而可以根據 App 構建所需時長反推出客戶端代碼集成需在某個時間點完成 (等同於開始構建測試包時間)。

• 前後任務之間存在時間上的空白（任務前置依賴滿足後任務開始時間滯後)

• 提升工作流平臺自動化能力，檢測任務前置依賴完成情況自動化的觸發

• 需人工進行的任務在固定的時間點或者前置依賴完成後增加提醒功能

• 提供事件訂閱機制，可以讓大家接收自己關注的事件通知，比如發佈計劃創建、App 開始構建、某個應用市場上架等

• 質量問題發現滯後

• 建立打包 / 灰度 / 全量前的卡口機制，線下環節或上次灰度中發現的問題在打包前必須標記已完成

• 要求各域在首次灰度時打開需驗證功能的開關

• 像版本號這樣的版本參數，在建發佈計劃時自動推斷出來填充表單

四

調整發布節奏

通過分析歷史發佈數據發現不同域在發佈節奏上有不一致的情況，通過與各職能業務線團隊溝通，節奏上我們做了如下圖所示的調整。調整後的時間線更加緊湊，服務端發佈和客戶端 App 打包時間提前了 4 個小時，首次灰度利用了夜間時間，使得灰度時間提前了 14 個小時。

五

雙端提升發佈系統自動化能力

圖片

在得物內部，我們有承載雙端開發、發佈和最終上架流程的工作流平臺。通過提升平臺的自動化能力和事件分發能力，顯著地提高了灰度發佈的效率。

自動創建發佈計劃

每個版本發佈前需要提前創建發佈計劃，參數包括版本號、計劃 App 打包時間、計劃灰度時間。

• 自動推斷版本參數: 防止手動填寫錯誤，根據得物 App 版本號規則和上一次發佈的版本參數，自動推斷此版本的 versionName、versionCode、buildNumber 等參數。

• 首個版本自動創建發佈計劃: 首個版本的計劃 App 打包時間、計劃灰度時間是固定的，在合適的時間點自動化的創建出來可以防止版本 owner 忘記操作。

打包 / 灰度 / 全量前卡口

App 打包前 / 灰度前 / 全量前都有相應的前置檢查項，比如隱私合規、代碼是否合入、線下包崩潰以及上次灰度的問題是否解決、包體積是否達標、三方組件審批情況等等。很多檢查能力分散在各個子系統，依賴人工檢查工作量較大且容易出錯，因此提供了流程上的卡點能力。

App 打包前置依賴提醒

組件集成和未解決的線下 Crash，推送消息至問題負責人和大羣的提醒。

• 線下 Crash 提醒

  測試環境的包出現崩潰時會有上報，我們的流程要求灰度發佈前必須全部解決掉，在灰度前 3 天開始推送提醒，在灰度當天在大羣中提醒。

• 組件集成提醒（業務組件集成、snapshot 組件 release）

自動打包

• 首個灰度版本前置依賴滿足後自動打包:  首個灰度版本打包前置依賴任務和檢查項較多。

• 計劃發佈時間打包:  到了預設的發佈時間自動觸發一次 App 構建。

• KOL 渠道自動打包:  爲了防止應用寶抓包造成渠道錯亂，新版本一般是等待應用寶審覈通過後，版本 owner 主動觸發 KOL 渠道包的構建，監控應用寶上架自動觸發。

測試迴歸催收

灰度包出包後客戶端版本 owner 手動提交審批 (版本號、包下載地址等)，然後把審批實例發送到灰度發佈大羣中。防止 QA 迴歸完成後忘記在系統上操作，做了快到計劃迴歸完成時間時把尚未通過的 QA 自動拉到飛書羣中，一方面可以提醒 QA 另外可以詢問測試卡點。

事件訂閱

整個發佈過程中特定職能的人員、系統，會關心某些事件，例如打包成功、發佈計劃創建、提測等等。

工作流平臺把很多外部會興趣的消息封裝成統一的事件對外部分發，支持在前端對某個事件配置飛書通知的接收人 / 羣，外部系統也支持通過 DMQ、HTTP 兩種協議來接收事件。

Android 應用市場上架監控

以往想知道某個市場上架情況，只能使用相應品牌的手機去查看，自動化的上架監控能及時把上架消息通知給關注者。

iOS 定製化蘋果商店

定製化蘋果商店基於 AppStoreConnectAPI 搭建一套商店系統。目的解決蘋果商店操作權限管控力度過大、無操作記錄、無進度通知、學習成本高、一次提審和發佈需要操作多個系統等問題。系統包含應用管理、版本創建，支持版本預覽圖、審覈信息、附件、提審包配置，支持版本提審、版本放量、版本審覈進度監控。實現一站式、一鍵式、可跟蹤的提審發佈系統。

六

總結

如何把高質量的新版本及時的觸達用戶，得物 App 在這一方向上持續投入了大量精力，在各部門通力合作下延期時長下降了超過 7 成，全量發佈最終實現了每版本平均提前一天的業務效率。

• 文 / tongyapeng

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/dpqfdPYe7TB1F-dxAFf62Q