就是福氣啦: Testflight 取代方案分析＆fabric 使用心得

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

iTunesConnect 的TestFlight
HockeyApp
蒲公英
Fabric (Crashlytics Beta)
自己架內部網頁

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

第二個出局的是iTunesConnect 的TestFlight，雖然在TestFlight的信裡鼓勵大家轉到iTunesConnect 去做發布測試，實際測試結果也蠻快的。但他有兩個致命性的問題：

沒有api，不能與CI結合
只有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。