【ITニュース解説】Expo + Maestro CI Pipeline Overviews (EAS Custom Builds, Maestro Cloud)

モバイルアプリの開発では、コードに変更があるたびに、それが正しく動作するか確認することが非常に重要だ。この確認作業を効率的に自動化するのが、CI/CD（継続的インテグレーション・継続的デリバリー）と呼ばれる仕組みだ。CI/CDパイプラインを構築することで、開発者はコードの品質を維持し、迅速に新しい機能をリリースできるようになる。この記事では、Expoというモバイルアプリ開発のフレームワークと、MaestroというUIテストツールを組み合わせて、どのようにCIパイプラインを構築するかを詳しく解説する。特に、Expoが提供するEAS Custom Buildsと、MaestroのクラウドサービスであるMaestro Cloudという二つの方法を比較しながら、その設定方法や具体的な運用について説明する。

私たちが構築したCIパイプラインは、GitHubというコード管理サービスを活用している。開発者が作成した新しいコードをmainブランチという主要なコードラインにプッシュ（送り込む）すると、それが自動的にGitHub Actionsという機能のトリガーとなる。GitHub Actionsは、GitHub上で定義された一連のタスクを自動で実行してくれるサービスだ。このワークフローが開始されると、まずアプリ開発に必要な依存関係がインストールされ、次にExpoのコマンドラインツールであるEAS CLIが導入される。その後、EAS CLIを使って、特定のビルド設定（ここではbuild-and-maestro-testというプロファイル）でアプリのビルドが実行される。ビルドが完了すると、もし問題が発生した場合に原因を特定できるよう、ビルドの成果物（完成したアプリのファイル）や実行ログが保存される仕組みになっている。

CIパイプラインを構築するにあたり、私たちはEAS Custom BuildsとMaestro Cloudという二つの選択肢を検討し、実際に両方の方法を試して有効性を確認した。EAS Custom Buildsは、Expoが提供するアプリケーションビルドサービスで、開発者が定義したカスタム設定に基づいてアプリをビルドできる。一方、Maestro CloudはMaestroというテストツールのクラウドベースのテスト実行環境で、物理デバイスやエミュレーターの多様な組み合わせでテストを実行できる。最終的に私たちは、コストを最重要視してEAS Buildを採用することにした。具体的な費用で比較すると、EAS BuildのStarterプランが月額約19ドルであるのに対し、Maestro Cloudは約212.50ドルと、Maestro Cloudの方が大幅に高額だったからだ。機能的にはどちらも要件を満たすことができたが、費用対効果を考慮し、EAS Buildを利用したパイプライン構築が最適だと判断した。

EAS Custom Buildsを利用する場合、アプリのビルド設定はeas.jsonというファイルに記述する。ここではbuild-and-maestro-testという名前のビルドプロファイルを定義している。このプロファイルでは、認証情報なしでビルドできる設定や、build-and-maestro-test.ymlという外部の構成ファイルを指定している。Androidアプリの場合はAPK形式でビルドし、iOSアプリの場合はシミュレーターで動作させるためのビルドを行うよう設定している。これらはどちらも最新のビルド環境イメージを使用するよう指定されている。 このビルドを実行するGitHub Actionsのワークフローは、mainブランチへのプッシュまたはプルリクエストを検知して起動する。ワークフローはUbuntuの最新版環境で実行され、最大120分まで処理を継続する。具体的なステップとしては、まずリポジトリのコードをチェックアウトし、次にJavaScriptの高速ランタイムであるBunをインストールする。その後、Bunを使ってプロジェクトの依存関係をインストールし、EAS CLIをグローバルにインストールする。最後に、Expoの認証トークンを使って、Androidプラットフォーム向けにbuild-and-maestro-testプロファイルでEASビルドを実行する。この際、対話なしで自動的に処理が進むように設定されている。

もう一つの選択肢であるMaestro Cloudを利用する場合も、GitHub Actionsのワークフローで自動化を行う。このワークフローは、どのブランチへのプッシュでもトリガーされるように設定されている。初期のステップ（リポジトリのチェックアウト、Bunのインストール、依存関係のインストール、EAS CLIのインストール）はEAS Custom Buildsの場合と同様だ。 Maestro Cloudでテストを実行するためには、まずテスト対象となるアプリのビルド済みファイル（Androidの場合はAPKファイル）が必要になる。このワークフローでは、Expoの認証トークンを使用して、EASビルドで生成された最新のAndroidプロダクションビルドの情報を取得する。取得した情報からビルドファイルのダウンロードURLを抽出し、そのURLを使ってAPKファイルをダウンロードする。この際、jqというコマンドラインツールを使ってJSON形式のレスポンスから必要な情報を抽出する処理や、curlコマンドを使ってファイルをダウンロードする処理が含まれている。APKファイルがダウンロードされたら、次にMaestro CLIをインストールし、その実行パスを設定する。これでMaestroのコマンドが使えるようになる。最後に、action-maestro-cloudというGitHub Actionを利用して、Maestro Cloud上でテストを実行する。このアクションには、Maestro CloudのAPIキーやプロジェクトID、テスト対象のAPKファイル、テストスクリプトのワークスペースパス、AndroidのAPIレベルなどの情報が渡される。さらに、テスト環境で使用するユーザーのメールアドレスやパスワードなどの機密情報も環境変数として安全に渡すことができる。

モバイルアプリの自動UIテストは、しばしば不安定になる（いわゆる「flaky test」）ことがある。これは、テストが毎回同じ結果を返さず、成功したり失敗したりする現象だ。このような不安定さを避けるために、いくつかの工夫が必要になる。例えば、ダイアログなどのUIコンポーネントと操作する前に、短い遅延（待ち時間）を入れることで、UIのレンダリングが完了するのを待つことができる。また、UI要素に設定されたIDが信頼できない場合や存在しない場合は、画面上のピクセル座標を指定して操作を行う手法も有効だ。動的に変化するデータをテストに利用したい場合は、runScriptという機能を使ってJavaScriptコードを実行し、動的なロジックをテストに組み込むことができる。これらのヒントは、私たちが実際の運用で得た経験に基づいている。ローカル環境でのテストは、Pixel 5のエミュレーター（Android APIレベル33）を使用して検証を行っていた。

このように、ExpoとMaestro、そしてGitHub Actionsを組み合わせることで、モバイルアプリの開発におけるビルドとテストのプロセスを効率的かつ自動的に実行するCIパイプラインを構築できる。これにより、開発者は品質の高いアプリをより迅速にユーザーに提供することが可能になる。