Github Actions連携の実機モバイルCIを作った
DIMBULA
実機モバイルで動作するCIプロダクトを作りました。
CI領域の中でも、E2Eテストにフォーカスしたプロダクトです。
プロダクト名は「DIMBULA」
私は、コーヒーと紅茶が大好きで、GithubにコードをPushしたとき、コーヒーや紅茶を淹れて一息つきます。このリフレッシュをもたらす時間に、DIMBULAとGithub Actionsは仕事をしてくれます。
プロダクトは、2つのサービスに分かれます。
- DIMBULA Computing - 実機モバイルを、ブラウザで一時利用できるサービス
- DIMBULA E2E - Github Actionsと連携した、実機モバイルのE2Eテストサービス
DIMBULA Computing
実機モバイルをWebブラウザで利用できます。カスタマーサポート等で、エンドユーザが使う同一のモバイルでデバッグが必要になったケースや、後述するDIMBULA E2Eのテスト条件や手順を作成する目的で利用されることを想定したサービスです。
技術的にはシンプルで、実機モバイルの画面をWebRTCで配信しているだけです。ブラウザからは、タップやスワイプ、テキスト入力や電源ボタンなど、データチャンネルを使って実機モバイルに関する操作が遠隔でできます。
DIMBULA E2E
E2Eテスト自体の説明は割愛しますが、ユーザの目線でテストシナリオを作成し、ユーザインターフェース上の問題がないかを検証する目的と理解しています。このサービスも、その目的で利用されることを想定していますが、実機モバイルであることが特徴と言えそうです。
実機モバイルであることの何が良いのか。実は私、世のE2Eテストサービスを使ったことがありません。故に、E2Eの重要性に気付いて、プロダクトまで作ってしまった感はありますが、実機である安心感やハードウェア連携といったところでしょうか。正直に言うと、今の時点で明確な答えを持ち合わせいません。今後の開発ではユーザの声を反映させていきたい所存です。
技術的に尖った要素はなく、Github ActionsでDIMBULA E2Eがリクエストされると、指定の条件に一致する空きモバイルを検索して、アプリのインストール、テスト手順の実行、結果を通知と基本的なHTTPの会話で済みます。
特徴
実機モバイル以外の特徴です。
Slack連携
DIMBULAは、Slackアプリのインストールが必須で、Slashコマンドを介してDIMBULAと対話的にコミュニケーションを取ります。また、DIMBULAを利用するために、ユーザ作成や招待といった機能はありません。Slackのワークスペースに参画するユーザであれば、Slackアプリをインストールするだけで利用できます。
Github Actions連携
DIMBULA E2Eを利用するユーザは、DIMBULAのGithubアプリのインストールが必要で、ChecksのREAD/WRITEのパーミッションを要求します。Githubのブランチ保護機能の1つに、マージ前にChecksがパスしているかどうかを設定できる機能がありますが、DIMBULA E2Eは、Checksの作成と更新を行いますので、この強力なブランチ保護機能に作用できるE2Eテストになっています。
E2Eテストはノーコードで定義
テストしたいモバイルやOSバージョン、言語の他、テストする操作はYAML形式で記述しますが、ノーコードであるものの、却って手間に感じることがあるでしょう。DIMBULA Computingでは、操作の記録とYAMLファイルへのダウンロード機能を備えていますので、YAMLファイルを作成する際にご利用いただけます。
エッジコンピュータ
実機モバイルを制御するために、シングルボードコンピュータを実機モバイルとペアで配置しています。役割は、前回の利用したユーザのブラウザセッションやアプリなどが残らないよう、次の利用者が使う前に、クリーンな状態にリストアします。また、WebRTCで画面を配信したり、OSの言語を変えたり、モバイルの操作を指示すること等を行っています。
E2Eテストでは、このコンピュータがテスト手順を実行するため、テストコード自体の不具合を無くし、テストコードが与える端末リソースへの影響を低減しています。
DIMBULA E2Eの流れ
E2Eテストする条件や手順等の事前準備は必要ですが、一度設定すれば、操作や条件に変更が無い限り、手を加える必要はありません。この流れは、Github Workflowの定義に従い、Actionsが実行され、DIMBULA E2Eがどういう流れで進んでいくかを図にしたものです。事前準備を除けば、ユーザがやらないといけないことは、テスト結果を確認し、Checksを更新するときだけです。
技術スタック
特に真新しさはなく、基本的には自分にとって作りやすさを重視した構成になっています。
Firebase Authentication
Slackのユーザを使うとはいえ、認証は必要です。Custom Claimを使うなどして、フロントエンドから直接StorageやFirestoreを利用する際には、適切なClaimが存在するユーザを判断します。
Firebase Functions
Slashコマンド、GithubのWebhookなど、エンドポイントはFunctionsです。
Firebase Storage
テストするアプリやその結果、エッジコンピュータのファームウェアは、ストレージで管理しています。
Firebase Firestore
データの永続化の他、データのリアルタイムなリスナー機能が強力で、空き端末の検索等で活躍しています。
Firebase Hosting
ReactJSで開発したWeb側をホスティングしています。
AWS Cognito
AWS方面でも認証・認可が必要なので、Cognitoを使っています。
AWS IAM
Cognito、KMS、KVSあたりでAssume Roleしています。
AWS Kinesis Video Stream WebRTC
画面の配信は、KVS WebRTCを使っています。
AWS Key Management Service
暗号化に必要なデータは、KVSを使います。
プロダクトのこれから
プロダクトが現在提供する実機モバイルは限定的ですが、実際に利用したい方の声を聞いて、調達したいと考えています。
機能面について、大きくは以下のことを考えています。
- エッジコンピュータ内にDockerもしくはそれ相当のコンテナを実行
- 社内リソースにアクセスするため、エッジコンピュータの社内ホスティング
前者は、エッジコンピュータ内にDocker等を構築・起動させて、ローカルAPIサーバーが立てられれば、インターネットに出て行くことなくクローズドな環境でテストできる恩恵は、何かとあると思います。
また後者については、自社が所有するモバイルを使いたいときや、自社の設備やIoTプロダクトとWi-FiもしくはBLE連携するようなアプリの開発で効果を発揮します。
もう1つ考える発展としては、プロダクトのOSS化。正直なところ、実機モバイルを将来にわたって調達し続けること、提供するインターネット回線の品質を維持すること、物理的に実機とエッジコンピュータを配備するスペースを確保し続けることができるのか、心配なところがあります。そこは収益化する暁になんとかなる可能性もありますが、自社で運用できるユーザは自社で出来る方が良いという考え方もありますので、選択肢としてOSSということも現時点であります。幸いこのプロダクトは開発者向けサービスですので。
Zennの使い方
技術的な面の紹介記事の他、検討中の機能や機能リクエストをスクラップで行っていきたいと思います。また既知の不具合や未対応の機能他、Slack Enterprise Gridについて動作確認できていないので、そういったところでもし協力できる方いましたら、スクラップに参加いただけると助かります。
最後に
このプロダクトを作るにあって、具体的な市場調査はしませんでした。BitriseやFirebase Test Labo、AWS Device Farmあたりが実機モバイル環境を提供している、とChatGPTで聞いた程度です。ただ簡単に使えて、CIプロダクトとして面白い特徴を作れれば、今後のモバイルアプリ開発に寄与できるのでは、とスタートしました。
直近は、テスト的にでも使いたいと興味をもっていただいた企業や個人の方へ導入の支援が出来ればと思います。その中で、機能的にも提供する実機モバイルの調達的にもニーズに即したプロダクトになるよう邁進します。
個人、企業の方問わず、使ってみたいという方、無料でご利用いただけます。
限定的な運用しており、混雑回避等のため、お手数ですが以下にご連絡ください。
SlackアプリのインストールURLを共有します。
もちろんご利用は無料です。
Discussion