本篇主要講解IOS app產品上架或者上線的流程,包含上線前準備、上架、發布以及後續追蹤
在上線的準備最重要的莫過於確定這個版本到底有哪些Feature包含在其中,可能有些人會覺得上線不就是一個版本一個版本迭代推進嗎?可能在公司規模小的狀況底下是如此,但即便如此有可能在開發時出現了時間差,有時候你以為Feature A可以順利在Feature B之前上線,但實際開發的時候卻會發生開發速率或者改變上線的順序或者隕石砸下來,造成很有可能需要變換版本的內容,如果公司超過一名PM時就必須清楚地在Release Plan中把所以應該要上線的東西寫下來,並且在每次變更版本內容時更新文件以確保接手的人不會誤把不該上線的上線。
另外就是版號,一般而言版號會有三個號碼,e.g. 3.15.5 → 3 代表主版號,15代表子版號,5代表修正版號,版號可以是兩個數字也可以超過三個數字,其實版號對於系統來說僅是紀錄一個版本的更新,但版本是給工程團隊自己清楚這個版本到底是什麼類型的更新的。
例如我們出了一個更改系統架構或者整個App翻新的版本,那就需要增加主版號,代表很有可能版本與上一個主版號時差異很大。一般上版Feature就會是子版號,而修正版號通常在修正一些錯誤或者極度小的部分時會更新,當然如果App很不穩定的話很有可能會看到修正版號一直增加的狀況。
每間公司對於版號都有不同的定義,但最重要的就是所有人都能夠理解,並且可以根據版號判定上線的Scope大概會多大以及很方便就查詢得到該版本的資訊。
在確定完上版的Feature後,需要將所有要上版的內容合併至同一個Branch,如果公司有在走git flow的話就是將所有功能合併進Develop並且切出Release,如果是走其他像是PR, MR的話就是要確保每個相關的Request都有被合併。
在上版前必須都要通過自動化測試,以確保沒有任何一個地方是有出現Bug的,當然有些公司沒有自動化測試,就只能手動跑測試。那如果沒有測試的話呢...那只好請PM自求多福了。
這個流程對App來說非常必要,由於通常都是分開維護App以及API server,開發新功能時一定也會更新API,但因為App更新是需要時間的,可能會出現新的App對舊API或者舊App對新API,如果沒有先經過相容性測試,很容易會讓App直接crash或者出現各種Bug,建議每次上版前都要測試看看並且先規劃好API server的更新。
接著就是打包出可以上架的檔案格式,並且上傳到App Store,完成上傳後,就可以進入下一個階段—上架。
在Apple Store中只要進入欲上架的App中並且點擊IOS app旁邊「+」 即可新增版本,並且打上版號。
文案包括版本資訊、App推廣文案、Keywords(像是SEO的Keyword,方便App被搜尋到)、支援網址等
App的截圖是非常重要的區塊,除了更清楚地讓客戶看到App的介面外,Apple其實偶爾也會審核一下App內部的介面是否跟上傳的截圖吻合。
App icon在App打包的時候就已經改了,如果要換icon的話就必須在打包前就先更改哦!
非常非常非常重要的就是 Sign-In Information,如果上架的是一個需要一打開就需要登入的App,沒提供的話就會直接被rejected哦!
確定版本資訊後就是送審,送審前需要回答三項題目,包括是否有使用廣告....,之後點擊送審,就可以看到App的狀態變成等待審核囉!
送審時也可以選擇App要手動發版還是設定時間一到自動發版。
Test Flight是IOS App內部測試的工具,只要在手機內安裝Test Flight並且成為內部測試人員,每當App送審後就可以在Test Flight中下載或更新自己的App做測試囉!
App在審核通過可以透過手動或者自動發布版本,要注意的是App上版與Web最大的不同就是App上版後需要時間才能讓所有的客戶下載到最新版本的App,如果有強制更新的設定要記得不要太早設定,否則就會造成客戶被強制更新但無法下載到最新版本的狀況。
在上線後,最重要的就是查看是否有任何Bug,App要裝偵測Crash的工具,例如:Firebase Crashlytics
App上架比較麻煩如果又是IOS App的話就必須考量到審核的時間,所以無法即時的修正出現嚴重Bug的版本,所以在上架的部分真的是需要嚴謹的流程以避免出現無法挽救的後果。
寓意科技提供專業的及系統資訊科技管理顧問服務,協助企業規劃並完成軟體建置
fable寓意科技官方網站:https://www.fable.com.tw/
fable寓意科技 Medium:https://medium.com/@fableltd