DMA01
產品上架/上市的流程介紹 (以iOS App部屬流程為例)

產品上架/上市的流程介紹 (以iOS App部屬流程為例)

What’s the process of delivering a product to the market(Use iOS App development process for sample)

寓意科技

本篇主要講解IOS app產品上架或者上線的流程,包含上線前準備、上架、發布以及後續追蹤

本篇主要講解IOS app產品上架或者上線的流程,包含上線前準備、上架、發布以及後續追蹤

 

上線前準備

  • 確定版本及其內容

在上線的準備最重要的莫過於確定這個版本到底有哪些Feature包含在其中,可能有些人會覺得上線不就是一個版本一個版本迭代推進嗎?可能在公司規模小的狀況底下是如此,但即便如此有可能在開發時出現了時間差,有時候你以為Feature A可以順利在Feature B之前上線,但實際開發的時候卻會發生開發速率或者改變上線的順序或者隕石砸下來,造成很有可能需要變換版本的內容,如果公司超過一名PM時就必須清楚地在Release Plan中把所以應該要上線的東西寫下來,並且在每次變更版本內容時更新文件以確保接手的人不會誤把不該上線的上線。

 

另外就是版號,一般而言版號會有三個號碼,e.g. 3.15.5 → 3 代表主版號,15代表子版號,5代表修正版號,版號可以是兩個數字也可以超過三個數字,其實版號對於系統來說僅是紀錄一個版本的更新,但版本是給工程團隊自己清楚這個版本到底是什麼類型的更新的。

 

例如我們出了一個更改系統架構或者整個App翻新的版本,那就需要增加主版號,代表很有可能版本與上一個主版號時差異很大。一般上版Feature就會是子版號,而修正版號通常在修正一些錯誤或者極度小的部分時會更新,當然如果App很不穩定的話很有可能會看到修正版號一直增加的狀況。

每間公司對於版號都有不同的定義,但最重要的就是所有人都能夠理解,並且可以根據版號判定上線的Scope大概會多大以及很方便就查詢得到該版本的資訊。

  • 整合Branch

在確定完上版的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

Test Flight是IOS App內部測試的工具,只要在手機內安裝Test Flight並且成為內部測試人員,每當App送審後就可以在Test Flight中下載或更新自己的App做測試囉!

發布

  • 發布版本

App在審核通過可以透過手動或者自動發布版本,要注意的是App上版與Web最大的不同就是App上版後需要時間才能讓所有的客戶下載到最新版本的App,如果有強制更新的設定要記得不要太早設定,否則就會造成客戶被強制更新但無法下載到最新版本的狀況。

檢查與追蹤

  • Firebase Crashlytics, Fabric

在上線後,最重要的就是查看是否有任何Bug,App要裝偵測Crash的工具,例如:Firebase Crashlytics

  • Similarweb, AppAnnie

 

緊急處理

  • 如果發布版本出現嚴重錯誤
  • 如果審核被reject

 

總結

App上架比較麻煩如果又是IOS App的話就必須考量到審核的時間,所以無法即時的修正出現嚴重Bug的版本,所以在上架的部分真的是需要嚴謹的流程以避免出現無法挽救的後果。

 

 

 

寓意科技
寓意科技

寓意科技提供專業的及系統資訊科技管理顧問服務,協助企業規劃並完成軟體建置

fable寓意科技官方網站:https://www.fable.com.tw/

fable寓意科技 Medium:https://medium.com/@fableltd

什麼是風險管理?
談數位管理的風險,是人人皆不想提的議題,但在這個時代,只要是想要運行或開發任何內部外部的資訊平台,就一定會有風險的發生,這邊將風險的影響力分成低中高,讓大家可以針對風險做一個初步了解。
如何應對「緊急但不重要」的事情?
這篇文章其實是將《和「電腦玩物」站長1對1諮詢,常見時間管理的問題與解答》的一部分內容抽取出並且補充說明,我不會針對「四象限法則」多做說明,網路上已經有許多相關的時間管理的文章可以閱讀,我想要分享的是:「不重要但緊急」的任務,其實是日常任務流程出現問題的警訊!
團隊的 GIT 分支管理策略 (3) : 持續整合以及相關比較
沒有一定說哪種方式比較好,不同的團隊組成適合的模式不同,但如果想要讓整個開發更為順暢、效能更加提高,提升成員們的技術並且往持續整合的方向移動是比較符合邏輯的選擇。