首先第一個出局的是蒲公英，雖然免費InHouse 好像很方便，但是身為一個有規模的公司，一點都不希望客戶打開你app的時候出現的使用授權跟是另一家公司的名字。而且蒲公英的做法完全違背了apple policy，哪天apple發現了扯到我們公司怎麼辦。
第二個出局的是iTunesConnect 的TestFlight，雖然在TestFlight的信裡鼓勵大家轉到iTunesConnect 去做發布測試，實際測試結果也蠻快的。但他有兩個致命性的問題：
- 沒有api，不能與CI結合
- 只有iOS 8 以上才能用，iOS 7沒辦法測
接下來放棄的是自架網頁，這其實蠻簡單的，以前在接案時也做過，可是可是可是層級一拉到公司就複雜很多。要做使用者管理，跟發註冊信，檢查使用者安裝狀況，還要分版本管理，一堆拉拉雜雜的事。跟以前只有把IPA丟到ftp然後產生一個連結比起來複雜太多了。可能要專門雇一個人來管理這個平台，評估起來效益不符。
於是就在Fabric跟HockeyApp之間做掙扎。
結果我們是選Fabric ，要說為什麼放棄HocketApp不如說為什麼為什麼要用Fabric，我在
自從推出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 還有客戶溝通上還算順暢，我想沒什麼大問題的話會一直用下去吧:)
crashlytics beta 從上個月底開始，大概也用了三個禮拜，上傳了30幾個版本，雖然有經過一些陣痛期，但是跟QA 還有客戶溝通上還算順暢，我想沒什麼大問題的話會一直用下去吧:)
