fastlaneを使ったiOSアプリのCI/CDにおける最低限作っておいた方が良いワークフロー

はじめに

普段iOSアプリの開発をしておりGitHubActionとfastlaneを使ってCI/CD環境を作る機会があったため、そのときに最低限あった方が良いと思ったワークフローをまとめました。

f:id:decoch:20200618170146p:plain

※ 証明書周りの管理はそれだけで文量が多くなるので今回は割愛します。

CIのワークフロー

CIとは

CIとは、Continuous Integrationの略で、継続的インテグレーションと呼ばれています。 CI(継続的インテグレーション)では、開発者が自分のコード変更を頻繁にセントラルリポジトリにマージし、その度に自動化されたビルドとテストを実行します。

このときに主に必要なワークフローは以下の2つです

1 lint設定

lane: lint do
  swiftlint(strict: true)
end

swiftlintだけではCIが失敗しないため注意が必要です。
CIで静的解析をちゃんと行いたい場合は strict: true のオプションをつけましょう。
その他のオプション: https://docs.fastlane.tools/actions/swiftlint/

2 Test設定

lane: test do
  scan
end

その他オプション: https://docs.fastlane.tools/actions/scan/

途中から導入しようとすると修正が必要なところが出てきて無駄に時間がかかってしまうため、
CIは開発を始める前に作ることを強くおすすめします。

CDのワークフロー

CDとは

CDとは、Continuous Deliveryの略で、継続的デリバリーと呼ばれています。継続的デリバリー(CD)は、継続的インテグレーション(CI)を拡張した手法で、ビルドやテストだけでなく、リリースプロセス全体を自動化します。

Stagingアプリの配布

lane :deploy_staging do
  gym
  # deploygate や firebase_app_distribution など
end

ビルドをし、できたipaファイルを Deploygate や Firebase App Distribution でテスターに配布をします

Productionアプリの配布

lane :deploy_production do
  gym
  deliver
end

ビルドをし、できたipaファイルを AppStoreConnectにアップロードします。

DSYMのアップロード

昨今のiOSアプリではクラッシュレポートとして、FirebaseCrashlyticsを使っていると思います。
その場合どこでクラッシュが起きたのかわかりやすくするために、AppStoreConnectにアップロードした後にFirebaseにdSYMファイルをアップロードする必要があります。

いままでプリの運用をしてきましたがアップロードは手動だと忘れがちなのでCIサービスを使って自動化をするべきです。

デプロイのフローに入れるとまだdSYMファイルがダウンロードできない場合があるため、CIサービスの設定などで1日1回定期実行すると失敗しなくなります。

lane :refresh_dsyms do |options|
  download_dsyms(
    app_identifier: 'xxxx',
    version: 'latest', 
    username: 'xxxx'
  )
  upload_symbols_to_crashlytics(
    gsp_path: './xxxx/GoogleService-Info.plist'
  )
  clean_build_artifacts
end

終わりに

最低限必要なワークフローとしては以下の5つがあるとよいです

Lint実行
テスト実行
Stagingアプリの配布
Productionアプリの配布
dSYMファイルのアップロード

これだけ設定するだけでも開発体験が大幅に改善します。

CIサービスには特に触れませんでしたが、iOSアプリではBitriseを使うと証明書のアップロードができたり、手順が丁寧にドキュメントにまとめられているのでおすすめです。 f:id:decoch:20200618170311p:plain

decochのブログ

フリーランスのiOSエンジニア decoch のブログです