こんにちは、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構成図
Android
GitHub Actions + Firebase App Tester/Google Play Console
GitHub Actionsの選定理由はもともとサーバーサイドでDrone CIを使っていてAndroidでも使っていました。Drone CIから移行し易くGHEを利用していて追加コストが掛からないといった点になります
AndroidアプリのCI構成図
行っていること要約
要するに何をしているのかというと以下の様なことです。
- ①developブランチへのPull request(以下PR)が更新された時 → ビルドとテストの実行
- ②developブランチpush時 → 開発中アプリの実機配布
- ③release/*ブランチがpush時 → ストア(App Store)への申請準備を行う
- ④masterブランチpush時 → releaseタグを付ける
- developブランチで毎週 → ビルドキャッシュ生成を行う(※iOSのみ。Bitriseのビルドキャッシュが7日で自動削除される為)
※Gitワークフローはgit-flowです。上記の各項目がどの部分に当たるか番号を図に記載しています。
引用元: http://nvie.com/posts/a-succesful-git-branching-model
License: Creative Commons BY-SA
行っていること詳細
行っていることを細かく記載するとこのような感じです。(一部)
①developブランチに対するPR更新毎にビルドとテストの実行
- GitHub Enterprise(以下GHE)のdevelopブランチに対するPRにpush
- BitriseでWorkflowを実行
- GHE、PRのStatusをpendingに変更
- GHEからclone
- Bitriseのビルドキャッシュを読み込む (ビルド時間短縮の為)
- fastlaneにてbuild可能な状態の準備を行う（XcodeGen、Carthage、CocoaPods等）
- fastlaneにて脆弱性チェック
※SAST(静的解析)ツールのinsider(https://github.com/insidersec/insider)を利用しコードの脆弱性をチェック - fastlaneにてユニットテスト
- fastlaneにて慣習化されたPRレビュー事項を自動コメント
※danger(https://github.com/danger/danger)を使用 - GHE、PRのStatusを成功失敗に変更
- Slackに成功失敗を通知
②developブランチpush時に開発中アプリの実機配布(iOS)
- GHEのdevelopブランチにpush
- BitriseでWorkflowを実行
- SSH keyを設定
- GHE、PRのStatusをpendingに変更
- GHEからclone
- Bitriseのビルドキャッシュを読み込む (ビルド時間短縮の為)
- fastlaneにてbuild可能な状態の準備を行う(xcodegen,carthage,cocoaPods等)
- fastlaneにてアップロードに必要なAppleの証明書/プロビジョニングのインストール
- fastlaneにてアプリケーションをアーカイブ
- fastlaneにてApp Store Connectへアーカイブをアップロード
- GHEにPush
- GHE、PRのStatusを成功失敗に変更
- 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モバイルアプリはどうやっているの」を紹介することで各環境で少しでも参考になりましたら幸いです。