最近会社ではリモートワーク体制になったことで、プッシュ通知設定の確認やアプリ内バナー表示といった、非モバイルアプリ開発者によるちょっとした動作確認に属人化が生まれたので、AWS Device Farm でなんとかした。

がっつり開発用途で使うとなれば、物理端末を購入するほうがコスト面において良い。しかし今回は毎日必要でないのと、1 日多くて 10 分程度のちょっとした確認であった。端末の購入コスト及び管理コストを踏まえると、AWS Device Farm のようなツールが良いと判断している。

導入

AWS 自体は省略。以下の流れで行った。

  1. 使用感を確かめつつコスト試算してマネージャーと話しつけておく

2. 対象のチームに試してもらい、使用感問題なさそうか聞く

3. 困った時に参照するドキュメントを整備

4. 必要であれば運用しやすくする仕組みを作成

書いてみるとまあそうだよねみたいな気持ちになった。

ドキュメントにはAWS Device Farm の使い方や、困ったときにはここへメンションしてといったような、運用する上で必要な事項を聞いた上で文書化している。文字だけ書かれても理解しづらいと思われるので、画像 (動く様子は GIF) をのせることで理解しやすいようにした。

AWS Device Farm プロジェクトの制限

AWS Device Farm ではプロジェクト単位でファイルをアップロードし管理することができる。

Android apk もアップロードすることができ、そのインストールをマウスぽちぽちでできるため、Play ストアに公開してないアプリでも簡単にインストールして動作確認できる。ただ、アップロードしたファイルを 30 日間しか保持しないので、定期的にアップロードするための仕組みを作成しておくのが無難。

権限を付与した専用のサービスアカウントを作成し、なんらかのタイミングでアップロードする。

必要な権限を持つサービスアカウントの作成

属人化を防ぐ意味で、apk をアップロードするためのサービスアカウントを作成する。miam を使うなら以下のようにユーザを作成し、access key id と access key secret を発行しておく。

devicefarm:UpdateUpload もあるが、Android apk は対応してないため、apk を更新するには削除と新規アップロードのステップが必要。

apk のアップロード

aws-sdk-devicefarm gem のように、様々な言語実装による SDK があるのでどれかを使うのが便利。僕はこの gem を利用し、Fastlane にのっかっている。

create_upload メソッドによって署名付き URL が含まれるレスポンスが返ってくるので、その URL に対して apk をアップロードするリクエストを行う。

Fastlane での apk アップロードリクエスト例

アプリのリリースフローに入れたり、毎週どこかの曜日で実行するなど、30 日より短いスパンで実行されるようなスケジュールを組んでおく。

AWS Device Farm を使う人向け設定

権限付与用の group を作成し、それをユーザに割り当てるのが良い。以下も miam を用いた場合の例。

おわりに

便利な世の中だ。