RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

【CI/CD】Bitrise、Fastlaneで取り組むiOSアプリ

はじめに

こんにちは、id:FM_Harmonyです。

ラクスの一部サービスではiOS向けのアプリを提供していますが、
今回はそれに関連して、iOSアプリ開発のCI/CDについてまとめてみました。

これからiOSアプリ開発のプロジェクトを始められる方、
既にあるプロジェクトにCI/CDを導入する方の参考になれば幸いです。

なお、「CI/CDとは?」といった部分に関しては、過去の記事に詳しいものがあるため、
そちらをご一読いただいてからこの記事を読まれますと、より理解が深まるかと思います。

tech-blog.rakus.co.jp

目次

Bitriseとは

公式サイトの説明によればBitriseとは、

Bitriseは、モバイルアプリ開発(iOS、Android、React Native、Flutterなど)に主に焦点を当てたサービスとしての継続的インテグレーションおよびデリバリー(CI / CD)プラットフォーム(PaaS)です。
これは、ソフトウェアプロジェクトの開発と自動化を支援するツールとサービスのコレクションです。

とのことです。

つまり、スマートフォン向けアプリでCI/CDを行うための環境を提供してくれるサービスという事です。

他にもCI/CD環境を提供するサービスはありますが、コスト面やワークフロー*1の作り易さから、
Bitriseの採用に至っています。

ラクスにおけるBitriseの利用についても、過去の記事がありますので、
よろしければ併せてご一読ください。
tech-blog.rakus.co.jp

fastlaneとは

こちらも公式サイトの説明によれば、fastlaneとは、

fastlane is the easiest way to automate beta deployments and releases for your iOS and Android apps. 
It handles all tedious tasks, like generating screenshots, dealing with code signing, and releasing your application.

とのことです。
つまり、スマートフォン向けアプリのリリースに関するタスクを自動化するためのツールという事です。

リリースだけでなく、自動テストやレポーティングといった機能も備えています。

BitriseだけでもCI/CDは行えるのですが、Bitriseがトラブルで利用できないときや、
コミット前にローカルでテストを動かしたいときを考え、

  • ビルドツールとしてfastlaneを使う
  • ビルド環境としてBitriseを使う

というように使い分けをしています。

実例紹介

CI / CD環境について

以下は、あるスマートフォン向けアプリ開発におけるCI / CDの環境構成の例になります。

図1:CI/CD環境

プロジェクトは社内のGitLabで管理しており、開発者がコードのプッシュ等を行うと、
Bitriseでビルド用の仮想マシンが作成されます。
その仮想マシンにプロジェクトのソースコードをクローンして、
fastlaneでのテストやビルドを行うといった構成です。

ビルドの終了時にはGitLabのPipelineに成功/失敗が通知されますが、
同時に社内のチャットツール(mattermost)にも通知されるようにしています。

これにより、開発者がGitLabを確認せずともCIの完了を把握できるようにしています。

図2:チャットツールへの通知例

では、具体的にCI / CDとしてどういったことを行っているか紹介します。

CIの取り組み

CI戦略

CIとしては、例えばfastlaneで以下を実行しています。

ユニットテストについては、Xcovでそのカバレッジを集計するようにしています。

基本的にはGitLabのマージリクエスト(MR)が作成、MRへコミットがプッシュされたタイミングで、
上記を行うようにしています。

というのも、2022年5月現在で利用しているBitriseのプランは、
同時に1ワークフローのみ実行可能なものであるためです。

Bitriseを利用しているプロジェクトはいくつか存在し、プッシュされるたびにワークフローを実行すると、
他プロジェクトのワークフローが待ち状態になることがあります。

それを避けるため、ワークフローの実行は必要最小限にしています。

ただし、masterブランチやリリース用のブランチはデグレードが発生した場合に速やかに修正する必要があるため、
コミットのプッシュごとにCIを実行しています。

図3:GitのブランチとCI戦略の関係

具体例

では、CIの実行例を見てみましょう。

CIが行われたとき、fastlaneにより実行結果のレポートが作成されます。
これにより、CIが失敗したときにその失敗理由を確認することが出来ます。

また、CIが失敗した際はDangerにより、失敗した箇所がMRにコメントされます。

fastlaneにより作成されたレポートはBitriseに保存されるのですが、Dangerも利用することで、

  • 原因が簡単に分かるものは、MRのコメントを基にコードを修正する
  • 詳細な原因を知りたいものは、Bitriseに保存されたレポートを基にコードを修正する

というようにでき、簡単なものであればBitriseとGitLabを行ったり来たりしなくても済むようにしています。

図4:Dangerによる静的解析のコメント例

さらに、ユニットテストカバレッジもDangerによるコメントを行っています。
これにより、

  • ここはカバーできているのでOK
  • ここはこういった理由でカバーしなくてもOK

といった情報を、MRのコメントでレビュワーに伝えています。

図5:Dangerによるカバレッジのコメント例

CDの取り組み

CD戦略

CDとしては、例えばfastlaneで以下を行っています。

  • アプリのバージョン番号変更
  • Test Flightへのアプリアップロード

ただし、以下の理由により必要なタイミングでのみ実行出来た方が都合がよいため、
CIと違って自動実行ではなく、手動でBitriseのワークフローを実行しています。

  • バージョン番号変更はファイルのコミットを伴う
  • アップロードに伴って変更されたビルド番号も含めた状態で、プロジェクトにタグを打つ運用になっている

また、事前にリリース時期の社内調整が必要なことがほとんどであるため、
アップロードしたアプリの公開も手動で行っています。

具体例

こちらも具体例を見てみましょう。

あるプロジェクトではそのバージョンの開発が完了すると、
成果物がコミットされたmasterブランチをreleaseブランチへマージし、
バージョン番号を変更するという運用を行っています。

バージョン番号変更においては、fastlane-plugin-versioningを利用しています。

以前はInfo.plistに設定された値を修正してバージョン番号を更新していたのですが、
Xcode 11よりBuild Settingに設定を行うようになりました。

fastlane-plugin-versioningはバージョン番号を渡すと、その辺りを考慮して適切に設定値を更新してくれるため、
バージョン番号変更に利用しています。

その後、プロジェクト全体の結合テスト等を経てリリース準備が完了すると、
releaseブランチでビルドしたアプリを署名してTest Flightへアップロードし、審査に提出しています。

このアプリビルドやアップロードについては、fastlaneで用意された機能を利用しています。
具体的には、

を利用するといった構成です。

また、アップロードにApp Store Connect APIを利用することで、
2段階認証を行うことなくBitriseからのアプリアップロードを行えるようにしています。

おわりに

いかがでしたでしょうか。
個人的な感想になりますが、CI/CD環境の整備により、

  • 実装コードに対する安心感が向上する
  • アプリビルドやアップロードの間もローカルマシンで別のことを行える

といった点で、それまでと比べて開発環境が改善されたと感じています。

今回の記事がiOSアプリでCI/CDを行う際の一案として、みなさまの参考になれば幸いです。


◆TECH PLAY
techplay.jp

◆connpass
rakus.connpass.com

*1:Jenkinsのジョブのようなもの

Copyright © RAKUS Co., Ltd. All rights reserved.