Bitriseできっとライズ

Bitriseに関する役立つ情報を共有します。弊社ブログに掲載してもいいという方はご一報ください！

はじめまして

 初めまして

 

Bitriseはユーザーの皆様にBitriseの多様性についてお伝えすべく、ブログを開設いたしました！

当社側からのポストもあれば、愛用者様のブログを引用しポストする場合もございます。アプリ開発をBitriseでもっと簡単にするためにご参考ください。

 

最初の記事は

伊藤様(@ito_nozomi)から

Bitriseの説明、セットアップ、自動テストまでわかりやすく書いていただきました。　協力していただいた伊藤様にはこの場をお借りして感謝申し上げます。ありがとうございます。

 

 

モバイルアプリのCIサービスBitriseと、弊社で運営している、ディープラーニング技術を活用したモバイルアプリ自動テストサービスMagic Podを使い、クラウドでiOSアプリのCIとUI自動テストを行う方法を紹介します。

CI + UI自動テストをうまく使えば、以下のように開発・テストの効率をあげることができます。

  • Pull Requestのタイミングでテストを実行し、レビューやマージの前に基本的な動作に問題がないか確認できます。
  • 定期的にテストを実行することで素早くバグを検出し、記憶が鮮明&他の開発者に影響が出る前に問題を修正できます。
  • 問題が起きそうな修正をいれたタイミングでも手動でビルド&テストを回すことで、変更内容に問題がないか素早くチェックできます。

Bitriseとは

Bitriseは、最近人気のiOS・Androidアプリのビルドをクラウド上で行えるCIサービスです。最近は色々なCIサービスがありますが、Bitriseには以下のような特徴があります。

  • 1回のビルドが10分以内なら無料でiOSビルドが可能
  • モバイルアプリのビルドに特化している
  • 図1のようなGUIでビルド設定が簡単に行える(iOSビルド周りがあまり得意でない私でもビルド設定できました。)
図1 Bitriseのビルド設定画面

ワークフローの設定内容はbitrise.ymlというファイルに集約されており、これを直接編集したり、Gitレポジトリで管理することもできるようです。1

Bitriseの初回セットアップを行う

まずはBitriseで新規のiOSアプリのビルド設定を行います。Magic PodのクラウドテストはiOSシミュレータ上で行われるので、iOSシミュレータに対するビルド設定をしていきます。

  • fastlaneなどを使ったプロジェクトのビルド方法は、今回は解説しません。
  • Bitriseの使い方については、こちらの記事がわかりやすくまとまっていて参考になります。

設定手順ですが、最初にBitriseのサインアップページ(図2)からユーザー登録を行い、

図2 Bitriseのサインアップページ

サインアップ完了後のページで「Add your first app」(図3)のボタンを押します。

図3 「Add your first app」ボタン

すると図4のアプリのビルド設定の画面になるので、ここでビルドの設定をしていきます。

図4 ビルド設定画面

必要な設定は以下の通りです。

  • CHOOSE ACCOUNT:
    • Bitriseの設定を一般公開するかを指定します。Privateでよいでしょう。
  • Connect your repository:
    • ビルドしたいiOSアプリのソースコードが入っているGitレポジトリを指定しましょう。GitHub/Bitbucket/GitLabが選べます。手元にちょうどいいアプリが無い場合、Magic PodデモアプリのプロジェクトをGitHub上でフォークして使用してもらっても構いません。
  • Setup repository access:
    • GitHubのサブモジュールの機能を使っているなど、追加で別のプライベートGitレポジトリにアクセスする必要がある場合は、「I need to」で必要な設定を行います。特に心当たりがなければ「No, auto-add SSH key」を選択しましょう。
  • Choose branch
    • masterなどの、ビルドするGitのブランチ名を指定します。

ここまで設定すると、Bitriseがレポジトリの内容を解析して、ビルド設定を自動で作成してくれます。

ここで、かなりの確率で図5のようなエラーメッセージが出ます。

図5 shared schemeのエラー
  • とりあえずiOSシミュレータでMagic Podのテストをしたいだけの場合は、「Proceed anyway」を選んで先に進んでください。
  • 直近で実機用のビルドも考えている場合は、ちゃんと修正した方がよいです。こちらの記事に従い、Xcode上でビルドShemeをSharedにして、xcshareddataをGitレポジトリにコミットしましょう。その後Bitriseのビルド設定に戻り、「Scan another branch」の項目を選んで(ブランチ名はそのままにします)、ビルド設定を再開します。

続いて「Select ipa export method」を選択するよう言われますが(図6)、Magic Podクラウドテストの場合は関係ないのでとりあえずad-hocを選んでおきます。2

図6 Select ipa export method

最後のWebhook setupを行うと、Gitレポジトリに変更が入るたびに自動ビルドが行われるようになります。ぜひとも「Register a Webhook for me!」を選んでおきましょう。3

以上で初回セットアップは終了です。最後に右上まで戻って「FINISH」ボタンを押すと自動でビルドが始まりますが、図7のように最初のビルドは失敗してしまうはずです。

図7 初回ビルド結果

Bitriseでシミュレータ用にiOSアプリをビルドする

初回のビルドが失敗した原因は、iOS実機用のビルドに必要な設定が不十分だったためです4。ですが、今回紹介する手順はiOSシミュレータに対するビルド設定なので、実機用の設定は削除して、シミュレータ用の設定に差し替えましょう。

まず、図7ビルド結果画面の左下にある「Open Workflow Editor」というボタンを押して、ビルドワークフローの編集画面に移動します。

ここで、「Xcode Archive & Export for iOS」を選択し(図8)、

図8 Xcode Archive & Export for iOS

そのまま上の方にスクロールして削除ボタンからこのステップを削除します(図9)。

図9 ステップの削除ボタン

次に、「Deploy to Bitrise.io - Apps, Lo...」のすぐ上の「+」ボタンを押し、Xcode build for simulator のステップを探して追加します(図10)。5

図10 Xcode build for simulator

ここまでできたら、画面右上の保存ボタンで変更を保存し、同じく画面右上の「×」ボタンでWorkflow Editorを終了して、同じく画面右上のRebuildボタンから再度ビルドを実行します。

今度はビルドが成功するはずです。(図11)

図11 成功ビルド

テスト作成に必要なappファイルを用意する

アプリの自動ビルドができるようになったので、次はMagic Podのクラウド端末を使ってテストを作成していきましょう。まずは、シミュレータ用アプリ実体ファイルであるappファイルを用意する必要があります。これには2通りの方法があります。

1. Bitriseでビルドしたappファイルをダウンロードする方法

簡単な設定を行えば、Bitriseでビルドされたappファイルがダウンロードできます。

まず、Workflow Editorから「Deploy to Bitrise.io - Apps, Lo...」のステップを選択し、「Deploy directory or file path 」に「$BITRISE_APP_DIR_PATH」を、「Compress the artifacts into one file?」に「true」を指定して保存し、再度ビルドを行います。(図12)


図12 「Deploy to Bitrise.io - Apps, Logs, Artifacts」の設定

ビルド後、ビルド結果の「APPS&ARTIFACTS」を確認すると、図13のようにappファイルをzip圧縮したものが取得できます。あとはこれをダウンロード・解凍すればappファイルが手に入ります。(zipファイルのままMagic Podのテストに利用すると、フォルダ構成のせいでうまく動かないので、一度解凍をする必要があります。)

図13 appファイル

2. Xcodeを使ってappファイルをビルドする方法

iOSアプリ開発者であれば、Xcodeを使ってappファイルをビルドする方が簡単かもしれません。こちらの手順に従えば、簡単にappファイルを作成することができます。

Magic Podでappファイルを使ってUI自動テストを作成する

続いてテストの作成です。こちらの記事に従い、Magic Podにユーザー登録し、先ほど用意したappファイルを使って適当なテストを作成してください。

テストの内容を後から変更・追加するのは簡単です。まずは「ユーザー登録するだけ」「ログインするだけ」などの簡単なもので良いので、テストケースを1つ作成しましょう。

図14 Magic Podのテストケース

BitriseからMagic Podのテストを実行する

いよいよBitriseとMagic Podを連携させます。テストが作成できたら再びBitriseのWorkflow Editorを開き、「Xcode build for simulator」ステップの下の「+」ボタンを押して「Magic Pod UI Test」のステップを追加します。(図15)

図15 Magic Pod UI test

追加できたら、以下の通り項目を入力しましょう。

  • Magic Pod API token
    • KeyにMAGIC_POD_API_TOKEN、ValueにMagic PodのAPIトークンページからコピーした値をセットします。
  • Organization name
    • Magic Podで使っている組織名を指定します。(「表示名」ではなく、組織のURLに使われているアルファベットの名前なので注意してください。)
  • Project name
    • Magic Podで使っているプロジェクト名を指定します。(「表示名」ではなく、プロジェクトのURLに使われているアルファベットの名前なので注意してください。)

他にも色々とパラメータがありますが、あとは初期値のままでも動きます。これで、BitriseでビルドしたアプリがMagic Pod側にもアップロードされ、CIのタイミングでテストが実行されるようになります。

終わったら修正内容を保存し、再度ビルドを実行します。無事テストが完了すれば、Bitriseのテスト結果メールに加え、Magic Podのテスト結果メールも配信されるはずです。(図16)

図16 テスト結果メール

ビルド&テストの自動開始のタイミングを調整する

初期設定のところでWebhookを設定した場合、GitレポジトリへのPushまたはPull Requestがあったタイミングで自動的にビルドが行われます。このタイミングは、以下の方法で調整が可能です。

  • こちらの手順に従えば、1日1回指定した時間にビルドを実行することができます。
  • Workflow EditorのTriggersタブ(図17)から、Push、Pull Requestなどのビルド開始のタイミングを調整できます6 。ビルド結果は自動的にGitHubなどの画面に連携され、PushやPull Requestに対するビルド結果を簡単に確認できます。(図18、図19)
図17 Triggersタブ
図18 Pushに対するビルド結果の表示
図19 Pull Requestに対するビルド結果の表示

テスト自動化の習慣を組織に定着させる最良の方法は、CIで定期的に実行することです。Magic Podには開発者に質問できるContactの機能(図21)もあるので、何か分からないことがあればお気軽にご質問ください!

図21 Contact