Testflight 取代方案分析&fabric 使用心得

自從1月底收到 TestFlight.com 2/26收起來的消息以後,就非常緊張,大概比較了一下幾個發布平台。上個月來說,討論的選項有:

首先第一個出局的是蒲公英,雖然免費InHouse 好像很方便,但是身為一個有規模的公司,一點都不希望客戶打開你app的時候出現的使用授權跟是另一家公司的名字。而且蒲公英的做法完全違背了apple policy,哪天apple發現了扯到我們公司怎麼辦。

第二個出局的是iTunesConnect 的TestFlight,雖然在TestFlight的信裡鼓勵大家轉到iTunesConnect 去做發布測試,實際測試結果也蠻快的。但他有兩個致命性的問題:
  1. 沒有api,不能與CI結合
  2. 只有iOS 8 以上才能用,iOS 7沒辦法測
接下來放棄的是自架網頁,這其實蠻簡單的,以前在接案時也做過,可是可是可是層級一拉到公司就複雜很多。要做使用者管理,跟發註冊信,檢查使用者安裝狀況,還要分版本管理,一堆拉拉雜雜的事。跟以前只有把IPA丟到ftp然後產生一個連結比起來複雜太多了。可能要專門雇一個人來管理這個平台,評估起來效益不符。

於是就在Fabric跟HockeyApp之間做掙扎。


結果我們是選Fabric ,要說為什麼放棄HocketApp不如說為什麼為什麼要用Fabric,我在
《讓你的App優雅的crash三部曲》 有提到crashlytics這個服務,可以很清楚的看到目前crash issue  的排名,找出最需要解的issue。所以現在寫的app 第一個裝進來的3rd party framework就是crashlytics,用了一陣子,也整了他的api,跟jenkins 、slack 配合得很好。
自從推出Answer 這個功能後統計功能又更上一層樓了。所以知道他也可以做發佈平台後就想來用看看。


Twitter 把Crashlytics 買下來以後,就重新包裝了一個服務叫Fabric,裡面以crashlytics 當主體,結合twitter 登入跟一些api,層級是Fabric >Crashlytics > Crashlytics Beta,所以說用Crashlytics Beta也可以。因為是一模一樣的東西,一模一樣的DB,只是有兩個domain name而已。

fabric 使用心得

上傳


首先在整合crashlytics的時候就會拿到app的key 跟secret ,上傳的時候會用到。只能用api 上傳,沒有另外的app可以輔助。比較麻煩的是要透過crashlytics framework裡面的submit  來上傳。script像這樣:

Crashlytics.framework/submit 
        ${API_KEY} ${BUILD_SECRET}
        -ipaPath ${ipaName}.ipa \
        -notesPath message.txt \
        -groupAliases ${groupName}

這裏需要注意的是groupAliases,以這張圖來說,我應該要填的是vide

大問題


crashlytics 有一個很麻煩的問題是他會把同一個bundleID,不管是什麼configuration的ipa 都會視為同一個app,不像以前testflight 可以開好幾個app,每個app都是同一個bundle_ID 但是連到不同的測試站。Crashlytics 只要bundle_ID一樣就會放在一起。
我們的解法是在buildNumber 那邊做手腳,以下面這張圖來說 (DevInHouse faf29f)。
有Dev出現的表示連到測試站,DevInHouse 表示是那個build 是用InHouse provision,至於最後面的 faf29f 表示是用faf29f這個commit。


每個build 展開來可以看到有哪些人,還有那些人有沒有裝app了,甚至有沒有開過app也知道。比Testflight 又更詳細了一點~


把人頭點開來可以看到這個人有哪些裝置已經註冊,可以重送Invitation 或把他移掉。
至於大頭照是連到gravatar上面抓的。



上個禮拜在cocoaheads  Taipei 裏也有討論要跳去哪裡,大家有整理出一篇完整的
我這篇負責補完crashlytics 的部分,想要用其他平台的可以參考上面那篇。

crashlytics beta 從上個月底開始,大概也用了三個禮拜,上傳了30幾個版本,雖然有經過一些陣痛期,但是跟QA 還有客戶溝通上還算順暢,我想沒什麼大問題的話會一直用下去吧:)