iOS開発におけるBitrise活用事例

この記事は[フラー Advent Calendar 2019](https://adventar.org/calendars/4155) - Adventarの20日目の記事です
昨日はNobux42さんで[GitHub Actionsを使ってReactアプリのCI環境を構築（Lighthouse CIも）](https://qiita.com/nobux42/items/b6170b599b4fa73256b3)でした

フラー株式会社でiOSエンジニアとその他諸々をやらせていただいているAtsushiIzuです。
フラー株式会社では、スマホアプリの実利用データを提供する[App Ape](https://ja.appa.pe/)というサービスと、アプリやウェブといったプロダクトをお客様と一緒に共創していく[共創スタジオ](https://www.kyoso-studios.com/)という2つのサービスを展開しています。

私は共創スタジオに所属しており、共創スタジオで使用しているBitriseについて触れていきます

# Bitriseとは？
Bitriseはハンガリーにオフィスを構えており、BitriseというCI/CDサービスを展開しています。
基本的にすべてGUI上で設定が行なえ、難しい設定をすることなく使用できることが特徴と考えています。

フラーでは、2016年からアプリのビルド・配信において、すべてBitriseで行っております。

※ちなみに、ハンガリーは温泉で有名ですが、フラーも[福利厚生で温泉に入れる](https://note.com/fuller/n/nf08db58c8eef)ことで有名(？)です

# フラーでのBitrise活用事例
フラーでは、各種ツール類としてFirebase、ビルドツールとしてfastlaneを使用しております。
これらを使うときに、各種処理が必要となりますが、これをBitriseにより自動化しています。

また、一部プロジェクトでサーバレス構成としてFirebaseを利用しておりますが、
Firebaseのfirestoreのコンテンツ更新もBitriseを用いて簡単に行っております。

これらについてフラーでの事例を紹介していきます！

## dSYMのアップロード自動化
まずはdSYMのアップロードの自動化です。
フラーではクラッシュ検知としてFirebase Crashlyticsを使用しています。

Crashlyticsでは、クラッシュ箇所を特定するために、dSYMのアップロードが必要となります。
bitcodeを有効にしている場合、App Store Connect側でバイナリの最適化を行うため、App Store ConnectからdSYMをダウンロードして、Crashlyticsへアップロードする処理が必要となります。

バージョンが上がるたびに必要ですが、毎回やるのはすごく大変だし、忘れがちなのでBitriseを用いて自動化しています。

Bitriseのワークフローとしてはスゴくシンプルです。

<img width="357" alt="スクリーンショット 2019-12-20 15.12.03.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546638/46a7dd0d-bbeb-b8eb-a138-d95951cc8b5e.png">

fastlaneのレーンを実行して、その結果をSlackに通知しています。

実行するレーンもシンプルで、App Store Connectから取得して、アップロードして、クリーンするだけです。

```
    # dsymの取得
    download_dsyms(
      username: "user name",
      app_identifier: "bundle id",
      team_id: "team id",
      min_version: "1.0.0" # 更新するミニマムバージョン、このバージョン以降を取得する
    )

    # dsymのアップロード
    upload_symbols_to_crashlytics(
      api_token: ENV['CRASHLYTICS_API_TOKEN'] # CrashlyticsのAPIトークンを設定する
    )

    # Clean
    clean_build_artifacts # dsymのクリーン
```

簡単ですね :tada: 

Bitriseでは手動ビルドの設定のところからスケジュールの設定ができるため、
フラーでは毎日6:11にこのレーンを稼働させています。

<img width="599" alt="スクリーンショット 2019-12-20 15.16.13.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546638/49814374-0a17-e3ab-7738-356cc3c9cd50.png">


## Provisioning Profileの更新自動化
次にProvisioning Profileの更新の自動化です。
フラーでは諸事情によりEnterpriseアカウントを所有していないため、App Store Connectに各自のデバイスを登録して、Provisioning Profileを更新する運用を行っています。

Provisioning Profileの更新自体はfastlane matchを用いてある程度楽をしているのですが、
誰かが機種変をするたびに、毎回Provisioning Profileを更新するのは地味に面倒で課題となっていました。

そこで、デバイス一覧をGitHubで管理して、masterブランチにプッシュされるたびに全Provisioning Profileを更新するようにしました。

Bitriseのワークフローとしてはこちらもシンプルでfastlaneのレーンを稼働しているだけです。

<img width="362" alt="スクリーンショット 2019-12-20 15.21.29.png" src="https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/546638/125c24c3-0bca-ee72-d863-b288ee56e344.png">

レーンの中身としては、fastlane matchを実行しているだけになります。
Development/AdHoc/AppStore分のmatchを実行して、Provisioning Profileを更新します。

```
    # Developmentの例
    match(
      type: "development",
      app_identifier: development_app_identifiers,
      team_id: team_id,
      username: username,
      git_url: git_url,
      clone_branch_directly: true,
      force_for_new_devices: true
    )
```

簡単ですね！ :tada: 

## Firebase firestoreのコンテンツ更新
おまけです。
Firestore上にコンテンツを配置して、アプリ側で利用していますが、そのコンテンツ更新にBitriseを使用しています。
TypeScriptでスクリプトを書き、そのスクリプトをBitrise上で動作させることでコンテンツの更新を行っています。

詳細は↓こちらにまとめてありますので、こちらを確認ください！

https://note.com/fuller/n/n4b322586d41b

# まとめ

簡単ではありましたが、普段やるにはちょっと面倒な処理をBitriseを使うことで楽に行っています。
皆さんの参考になれば幸いです！