如何進行APP版本升級管理?
在產(chǎn)品工作中,經(jīng)常要對產(chǎn)品APP進行迭代升級。本文作者根據(jù)自己的工作經(jīng)驗,對APP版本升級管理這個問題展開了深入的思考,希望對你有幫助。
移動端功能開發(fā)測試完成后,需要引導用戶安裝新版本,針對用戶量級較大的APP這個過程中會分為兩個階段:灰度階段和正式階段。
灰度階段是面向部分用戶投放應用,目的是驗證應用包的可用性及兼容性問題。正式階段是面向全量用戶投放正式的應用,目的是引導用戶升級到新的版本。
實施方式:
灰度階段有兩種方式:APP灰度——全量功能APP分發(fā)給部分用戶試用。功能灰度——部分功能由后臺控制開關供部分用戶使用正式階段(全量開放):經(jīng)檢驗沒有問題的APP上傳到各應用市場,同時引導老用戶進行版本升級
本文僅針對正式階段,面向全量用戶進行新版本升級引導的APP版本升級管理進行展開討論。
版本升級流程:
版本升級總共分為兩步:安裝包發(fā)布到官網(wǎng),引導用戶升級到新版本。
流程圖如下:APP官網(wǎng)投放、iOS需要上傳appstore審核,安卓可依據(jù)需求投放不同應用市場。
特別說明:因為App Store存在審核時間長的特性(3-14天不等),如果需要兩端同步發(fā)布一般是需要先將iOS端進行提審,再講安卓提審(安卓應用市場審核周期為一天左右),等到應用包已經(jīng)上架應用商店后,接下來就是引導已經(jīng)安裝APP的老用戶進行升級到新版本各應用商店有自己的應用升級方式。
但是升級過程會很被動(比如用戶關閉自動升級,新版本存在功能不兼容導致用戶不能使用),所以需要我們自己開發(fā)管理后臺去控制各版本之間的升級方式
運營配置升級流程:
引導用戶升級需要在后臺做兩步:配置需要升級的安裝包信息,設置升級方案。
第一步:填寫安裝包信息
不同渠道的安裝包需要填寫的安裝包信息不同,iOS之所以分為三種發(fā)布類型是可以理解為兩個用途:appstore用于正式安裝包配置,企業(yè)分發(fā)/testflight為內(nèi)部測試升級使用。
testflight是蘋果提供給開發(fā)者專用的測試方式,用戶需要測試之前需要安裝蘋果提供的一個testflight工具,然后會收到開發(fā)者的測試升級邀請,或者通過開發(fā)者開放的一個公開鏈接去下載測試包。
testflight這種方式一是測試人數(shù)有上限(9999人),二是需要額外安裝工具。
內(nèi)部測試的話,也可以通過企業(yè)證書打包的方式,企業(yè)證書是面向企業(yè)內(nèi)部員工使用的APP的開發(fā)者證書。開發(fā)者只需要將應用打包,生成應用下載二維碼,這樣用戶就可以直接掃碼安裝。
兩者可以依據(jù)現(xiàn)實情況考慮,不是必要選項。
第二步:設置升級方案
這里面有兩種主流升級方式:依據(jù)最新版本升級方式引導升級,依據(jù)用戶當前所用版本升級方式引導用戶升級。
依據(jù)最新版本升級方式引導用戶升級:不管用戶當前所用版本,所有版本都是依據(jù)最新版的升級方式來升級的。
優(yōu)點:引導性強,可以快速引導全量用戶升級到最新的版本。
缺點:影響范圍廣,比如本次新版功能只針對上個版本用戶做了bug修復,需要強制升級,但是其他版本用戶雖然沒受到影響也需要跟著一起強制升級。
依據(jù)用戶當前使用版本的升級方式引導用戶升級:新版發(fā)布時,為每個歷史版本配置該版本的升級模式,比如新發(fā)布2.0.0版本,為1.2.0版本配置提示升級,為1.1.0版本配置不提示升級,為1.0.0版本配置強制升級。
優(yōu)點:針對性強,可以兼容歷史版本,用戶影響范圍小。
缺點:維護成本高,隨著版本數(shù)量增多,會存在需要維護的歷史版本多的情況所以升級方案參考了上面的兩種升級方式,采用第一種依據(jù)最新版本升級方式,但又補充了最小兼容版本,盡可能在用戶體驗及維護成本中平衡,先看下用戶端的升級判斷邏輯。
提醒用戶升級方式有四種:
升級策略的觸發(fā)條件除了最新版本配置的升級方法外,考慮到了歷史版本兼容性問題,增加了最小兼容版本的這個字段,就能滿足在固定版本以前無法正常使用,需要強制升級的邏輯場景。
最小兼容版本就是,最新版本升級邏輯僅支持的最小版本號,小于該版本的歷史版本均采用強制升級,保障用戶的基本使用體驗,其余版本則遵循最新版配置的升級邏輯。
版本管理列表:
新建版本:
客戶端升級彈窗:
總結:
做好一個移動端產(chǎn)品,除了需要研發(fā)新的功能滿足用戶的需求,還需要關注版本的更新迭代節(jié)奏。如何用更好的方式引導用戶升級,以及建立良性的迭代循環(huán)和版本兼容管理,都是值得思考的,如果更多的好的想法歡迎一起交流溝通~
本文由 @胡小圈兒 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議
我不理解當一個版本發(fā)布了以后,還要留著編輯按鈕的意義是什么
如果我發(fā)布了2.0版本的升級規(guī)則,設置了最小兼容版本是1.5,然后我又找到1,5版本的升級規(guī)則,將其改為強制更新,那么問題來了,這兩個規(guī)則有沖突,該如何運行呢?
我理解1.5版本的升級規(guī)則改為強制更新后,代表著所有低于1.5版本的都要升級到1.5;和2.0版本的升級規(guī)則中最小兼容版本為1.5不沖突。
但如果設置2.0版本的升級規(guī)則中最小兼容版本為1.0,此時編輯1.5版本的升級規(guī)則為強制更新,系統(tǒng)應提示與現(xiàn)有升級規(guī)則沖突,這樣是不是邏輯合理了一些
如果我發(fā)布了2.0版本的升級規(guī)則,設置了最小兼容版本是1.5,然后我又找到1,5版本的兼容規(guī)則,將其改為強制更新,那么問題來了,這兩個規(guī)則有沖突,該如何運行呢?
請問發(fā)布時間配置是用什么用的?
新建版本信息客戶端為安卓的頁面有嗎?
請問后臺管理界面需要區(qū)分安裝包是安卓哪個應用市場的嗎,所有安卓應用市場都上傳同一個包,用戶不在應用市場主動更新,而是通過鏈接直接安裝安裝包更新,后臺如何得知數(shù)據(jù)來源來自哪個應用市場呢
安卓app內(nèi)更新就可以
正要做這塊,非常感謝作者的分享
數(shù)據(jù)狀態(tài)指的是什么呢?
所有的版本都會推送升級到最新版本吧?比如1.0.1(普通更新版本),1.0.2(強制更新版本),1.0.3(普通更新版本),1.1.0(最新版),當前用戶的使用版本為1.0.1和1.0.3需要提示更新到1.1.0,1.0.2版本的使用用戶需要強制更新到1.1.0,1.1.0版本用戶就不需要更新了
寫的很詳細,受教了,有一點需要請教,這個最低兼容版本怎么定義
比如:有3個版本,1.0(最低兼容版本),2.0(強制升級),3.0(非強制升級)
3.0是最新版本
當前用戶是1.0,如果和最新版本去比較,那用戶是不需要升級的,但事實上不升級的話,是用不了的
請大神指教一下!
一下僅代表個人理解
就你例子來講的話有三個版本,3.0是最新版本,如果1.0被設置為最低兼容版本,就代表1.0能用,用不了的話,就把最低版本設置為2.0,1.0就能強制更新了
如果本人理解有誤,歡迎指正,
親,我理解是這樣,你2.0(強制升級)上線時,1.0(最低兼容版本)就不可能存在了,要被強制升級到2.0,你看下用戶升級的流程圖
應該是強制升級到最新版
如果用戶在2.0版本期間沒有啟動app呢
判斷1.0-3.0中是否有強制版本,有的話必需升級
你好,想請教些問題,方便交流下嗎?
寫得很細,正好是在做的功能很有幫助。有個疑問,就是版本信息里需要輸入appstore和testflight地址,這個不是一般一個app都是固定的嗎?為什么要是輸入的?
我也有這個疑問
有一點沒理解透徹,在上傳新版時,只需要填寫版本號,不需要version code么,那在做版本判斷時是直接用版本號來判斷么
你們是界面手動維護versioncode還是系統(tǒng)自動生成