SUZURI CI mobile

SUZURIモバイルアプリのCI/CD

SUZURI CI mobile

こんにちは、SUZURI モバイルエンジニアのsayhaです! 最近は暑さで寝苦しい上に子供がのしかかってきてうまく寝られず寝不足ぎみでつらみです。

今回は「SUZURIのCI/CD構成ってどうなっているの?」といった声が聞こえてきたのでSUZURIモバイルアプリのCI/CD構成についてご紹介したいと思います。

CI/CDとは
CI = Continuous Integration(継続的インテグレーション)
アプリケーション開発において自動化を取り入れることで、継続的にビルドやテストを行い正確迅速に開発を進める手法
CD = Continuous Delivery(継続的デリバリー)
継続的に配信を行い顧客にアプリケーションを提供する頻度を高める手法

CI/CDについて詳しく知りたい方は@k1lowさんの記事いまさら聞けない「CI/CD」の意義――GitHubとGitHub ActionsでCI/CDを試してみよう：GMOペパボに学ぶ「CI/CD」活用術をご閲覧ください

SUZURIモバイルアプリでCI/CDを行う理由

1人が1回行うのと違い、複数人が繰り返し行うと手間と時間が掛かります。そういった作業を自動化することでチームメンバーが簡単にサッと作業を行えたり、何もしなくても自動で作業が進みとても便利なのでCI/CDしています。
またリリース頻度の増加にも繋がっています。新バージョンリリースの際の申請作業は意外と手間隙が掛かるので自動化し作業の負担を減らすことで、リリース頻度は約4倍ぐらいに増えました。

使用サービスと構成図

CI/CDを構成しているサービスと関係について、iOSとAndroidそれぞれでご紹介します。

iOS

Bitrise + App Store Connect

Bitriseの選定理由はiOSのCIに特化していて扱い易くTravis CI、Circle CIといった他サービスと比較してコストが掛からないといった点になります。

iOSアプリのCI/CD構成図

iOSアプリのCI構成図

Android

GitHub Actions + Firebase App Tester/Google Play Console
GitHub Actionsの選定理由はもともとサーバーサイドでDrone CIを使っていてAndroidでも使っていました。Drone CIから移行し易くGHEを利用していて追加コストが掛からないといった点になります

AndroidアプリのCI構成図

AndroidアプリのCI構成図

行っていること要約

要するに何をしているのかというと以下の様なことです。

  • ①developブランチへのPull request(以下PR)が更新された時 → ビルドとテストの実行
  • ②developブランチpush時 → 開発中アプリの実機配布
  • ③release/*ブランチがpush時 → ストア(App Store)への申請準備を行う
  • ④masterブランチpush時 → releaseタグを付ける
  • developブランチで毎週 → ビルドキャッシュ生成を行う(※iOSのみ。Bitriseのビルドキャッシュが7日で自動削除される為)

※Gitワークフローはgit-flowです。上記の各項目がどの部分に当たるか番号を図に記載しています。 iOSアプリCI構成図

引用元: http://nvie.com/posts/a-succesful-git-branching-model
License: Creative Commons BY-SA

行っていること詳細

行っていることを細かく記載するとこのような感じです。(一部)

①developブランチに対するPR更新毎にビルドとテストの実行

  1. GitHub Enterprise(以下GHE)のdevelopブランチに対するPRにpush
  2. BitriseでWorkflowを実行
    1. GHE、PRのStatusをpendingに変更
    2. GHEからclone
    3. Bitriseのビルドキャッシュを読み込む (ビルド時間短縮の為)
    4. fastlaneにてbuild可能な状態の準備を行う（XcodeGen、Carthage、CocoaPods等）
    5. fastlaneにて脆弱性チェック
      ※SAST(静的解析)ツールのinsider(https://github.com/insidersec/insider)を利用しコードの脆弱性をチェック
    6. fastlaneにてユニットテスト
    7. fastlaneにて慣習化されたPRレビュー事項を自動コメント
      ※danger(https://github.com/danger/danger)を使用
    8. GHE、PRのStatusを成功失敗に変更
    9. Slackに成功失敗を通知

②developブランチpush時に開発中アプリの実機配布(iOS)

  1. GHEのdevelopブランチにpush
  2. BitriseでWorkflowを実行
    1. SSH keyを設定
    2. GHE、PRのStatusをpendingに変更
    3. GHEからclone
    4. Bitriseのビルドキャッシュを読み込む (ビルド時間短縮の為)
    5. fastlaneにてbuild可能な状態の準備を行う(xcodegen,carthage,cocoaPods等)
    6. fastlaneにてアップロードに必要なAppleの証明書/プロビジョニングのインストール
    7. fastlaneにてアプリケーションをアーカイブ
    8. fastlaneにてApp Store Connectへアーカイブをアップロード
    9. GHEにPush
    10. GHE、PRのStatusを成功失敗に変更
    11. Slackに成功失敗を通知

意識していること

CIサービスの上で設定する内容は、以下のGHE操作やWorkflowに関係することのみに留めていて実際の処理はfastlaneに集約しています。

  • BitriseからGHEへのアクセスの際の設定、clone、PR Statusの操作といったGHEの操作
  • Workflowの結果通知
  • 環境変数など

その結果、以下のメリットがあります。

  • 将来CIサービスをすげ替えても移行しやすい
  • 各人のローカル開発環境でも処理を流用できる

その他、各機能開発後にPRがマージされたdevelopブランチの最新開発版アプリが実機へ配布されている状態となっていることで、リリース前の動作検証がすぐに行えるように意識しています。

[補足情報] fastlaneで行っていること

lane名称 説明
bootstrap build可能な状態にセットアップを行う
insider insiderを実行する
tests すべてのテストを実行する
get_certs_profiles チームで使用してる証明書とプロビジョニングを取得します
update_certs_profiles チームで使用してる証明書とプロビジョニングを更新(作成)します
register_new_devices devices.txtにデバイスのIdentifier追加後実行するとプロビジョニングにデバイスを紐付ける
stg_testflight TestFlightにStaging向きのipaをアップロードする
prod_testflight TestFlightにProduction向きのipaをアップロードする
deploy_appstoreconnect App Store Connectにアップロードする
set_appstoreconnect_version App Store Connectに次のVersionNameを設定
set_privacy_details App Privacy Detailsを設定
add_tag Version Numberからgit tag を追加する
run_danger dangerを実行する

まとめ

SUZURIモバイルアプリのCI/CDについてご紹介しました。チーム開発でのCI/CDは改善点が無数に出現し、皆様日々改善ポイントを探しているかと思います。「SUZURIモバイルアプリはどうやっているの」を紹介することで各環境で少しでも参考になりましたら幸いです。

書いた人

  • sayha

    iOSエンジニア + Flutterエンジニア。アプリを作ってます。叩き上げ中のアプリエンジニアです。