こんにちは、i3DESIGNエンジニアの沈です。
今回は、弊社でモバイルアプリケーション開発で使用するCI/CDツールについてお話します。
目次
CI/CDとは？
CI/CDとは「Continuous Integration／Continuous Delivery」の略で、「継続的インテグレーション／継続的デリバリー」といいます。
後者(CD)は、前者(CI)を拡張した手法で、開発者によるアプリケーションへの変更に対して、ビルドやテスト、リリースデプロイまで一連のプロセスを自動化します。
CI/CDツール
CI/CDを実現するためのツールは大きく分けてオンプレミス型とクラウド型があります。
オンプレミス型は導入者自身が構築するため拡張性が高く、その反面運用コストがかかります。代表的なツールとしてJenkinsが最も有名かと思います（一部クラウド型の機能もあります）。
クラウド型は構築する必要なくすぐに使い始めることができるのが、大きなメリットです。かわりに大半は有料サービスで、拡張性がサービス提供元に左右されます。代表的なツールとして、CircleCI、Travis CI、Azure Pipelines、Bitriseなどがあります。
i3DESIGNが使うCI/CDツール
弊社のスマホアプリ開発現場では、「Bitrise」を導入してます。
Bitriseとは？
Bitriseはスマホアプリ開発に特化したクラウド型CI/CDツールです。
有料サービス（※無料枠あり）ですが、月額定額であるため、ビルド時間などを気にせず利用できます。
対応するプラットフォームは：Swift / Objective-C / Java / Kotlin / Xamarin / Cordova / Ionic / React Native / Flutter
ネイティブからクロスプラットフォームまで幅広く対応してます。
ジョブの作成は基本的にGUIを利用しますが、CLIも用意されています。
※ BitriseのWorkflowとBuildsのUI例
導入して良かった点
弊社では２２個のアプリケーションに導入、運用してきましたが、個人的に「良かった」と思えたポイントをまとめてみました。
- 初期セットアップが楽
- リポジトリ情報を入れたあとプラットフォームを自動チェックして、Workflow生成と環境変数設定をある程度してくれる。
- ステップ/アクションが豊富
- 大体のステップは用意されている。
- 既存ステップがない場合は、自前のScriptを実行できるのでカバーできる。
- リリースビルドに必要なサインイン情報をアプリケーションごとに管理できる
- iOSのコード署名証明書・プロビジョニングプロファイル、Androidのキーストア情報を設定する機能がある
- Slackなどのコミュニケーションツールとの連携が簡単にできる
- Slackチャンネルに繋げてビルド結果を送信できる
i3DESIGNでの活用例
CI/CDツールの基本となるビルド、テスト実行、デプロイ機能以外に、仕組みとして入れておくとより高い利便性と生産性を得られるステップをご紹介していきます。
ビルド番号の自動入力
iOSもAndroidも、リリースビルドをストアにアップロードする際、ダウングレード防止のためにバージョンとビルド番号をチェックされます。
バージョン番号は、すでに公開済みのバージョンより大きい値、ビルド番号はストアにアップロード済みの番号より大きい数値に設定されていないと、ストアに受け付けてもらえません。
今までありがちなのは、「一度リリースビルドをアップロードした後にバグが見つかり、修正して再度アップロードかける時にビルド番号を更新し忘れて、拒否される」というケースです。
それを防ぐために、Bitriseを用いて自動入力しています。
やり方はとても簡単で、以下のステップをそれぞれiOSとAndroid用のWorkFlowに追加します。
iOSのInfo.plistファイルとAndroidのbuild.gradleファイルのパスを指定し、ビルド番号を$BITRISE_BUILD_NUMBER という変数を使うように設定します。
$BITRISE_BUILD_NUMBER は、Bitriseが提供するもので、ビルド実行する度に自動インクリースされますので、ダウングレードの心配がありません。
製品版・テスト版アプリのアイコン差別化
アプリ開発において、製品版の他に、開発版やテスト版を別に用意するケースは多いかと思います。
製品版と完全に異なるUIで開発することもあるかもしれませんが、一般的には「接続先のサーバが違う」「表示するデータが異なる」がほとんどではないでしょうか。
今動かしているアプリはどの環境に向けているのか、ひと目でわかるようにするために、アプリアイコンの差別化を取り入れています。
使用するBitriseステップはこちらです。
既存のアプリアイコンに、任意のラベルをスタンプしてくれます。
AppIcon.appiconsetファイルのパスを指定し、ラベルとして指定したい文字列を入力します。
また、デフォルトでBitriseのビルド番号もスタンプされます。
クロスプラットフォームアプリのWorkflow Trigger
ネイティブ開発の場合、プラットフォーム毎にアプリケーションを登録、管理します。
Bitriseの自動ビルドも、大体はGitのPushイベントをトリガーとして設定しています。
React Nativeなど、クロスプラットフォーム開発の場合は、登録アプリケーションは一つで、Git Repositoryも一つなので少しややこしくなります。
プラットフォームに応じてそれぞれのWorkflowを作成できていても、トリガーとのWorkflowは一対一の関係しか指定できないので、同時に複数のプラットフォームをビルドできません。
ネイティブと同様にアプリケーションを分けないといけない、と考えてましたが、実はもっと簡単な方法がありました。
指定のWorkflowを実行するステップが最初から用意されていました。
ここの例では、「all」というWorkflowに、Trigger Bitrise workflowステップを追加します。
予め作成しておいた各プラットフォーム用のworkflowをステップに指定します。
最後にトリガー設定で、実行対象Workflowを「all」に指定すれば完成です。
これでトリガーイベントが発火した時、各プラットフォームのWorkflowが順番に実行されていきます。
最後に
いかがでしょうか。
以上、弊社のアプリケーション開発に導入したCI/CDツールのBitrise、そしてその活用例についてのお話しでした。現場ではさらなる活用方法を日々模索しています。
皆様のご参考になれたら幸いです。
