Bitriseできっとライズ

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

BitriseでAndroidビルドをしようとして右往左往した話

BitriseでAndroidビルドをしようとして右往左往した話

Android 技術ネタ CI Bitrise
 
今回の記事はsasanori-0126様のブログを引用させていただきました。
共感できる方もいるかもしれませんね！
笹海苔さまこの度はありがとうございました！

ちょっと仕事でBitriseを利用することになったので、そこで右往左往した話をご紹介

Bitriseとは

最近モバイルアプリ界隈で話題にCIサービス「Bitrise」

ドキュメント通りに何度試してもエラーに

oh... (´・ω・｀)

つまづきポイント1

アプリにNDKを利用している

....(ﾟдﾟ)

WorkFlowでSDKインストールと合わせてNDKインストールもしないとなのね！

つまづきポイント2

build.gradleでsingingの設定がすでに記載されている

....(ﾟдﾟ)

App BuildとAPK SinginじゃなくてGradle Runnerを使えばいいのね！

つまづきポイント3

なぞにSDKインストールで失敗する

....(ﾟдﾟ)

全部Fastlaneで実行して、laneだけ呼べばいいんじゃね？ (・∀・)ｿﾚﾀﾞ!!

つまづきポイント4

なぞにArtifactsでapkが取得できない

....(ﾟдﾟ)

....(ﾟдﾟ)

....(ﾟдﾟ)

余計なジョブ全部なくせばいいんじゃね？ ....ｺﾚﾀﾞ(ﾟдﾟ)+

SDKインストールやめました。

結果こんな感じに

f:id:sasanori-0126:20190526220405p:plain

個人開発なんかでもbuild.gradleにsingingの設定入れてる場合も多いのかなって思い、アウトプットしてみた感じです。

ymlファイルは下記に置いておきますね。

---
format_version: '7'
default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git
project_type: android
workflows:
  debug-deploy:
    steps:
    - activate-ssh-key@4.0.3:
        run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}'
    - git-clone@4.0.14: {}
    - script@1.1.5:
        title: Do anything with Script step
        inputs:
        - content: |
            #!/usr/bin/env bash
            # fail if any commands fails
            set -e
            # debug log
            set -x
    - cache-pull@2.0.1: {}
    - gradle-runner@1.9.0:
        inputs:
        - gradle_task: assembleDebug
        - gradlew_path: "$PROJECT_LOCATION/gradlew"
    - deploygate--upload-app-bitrise-step@1.0.1:
        inputs:
        - owner_name: xxxxxxxxxxxx
        - app_path: "$BITRISE_APK_PATH"
        - message: "[$BITRISE_BUILD_NUMBER] Debug Build [$BITRISE_GIT_BRANCH] ($BITRISE_GIT_MESSAGE)"
        - api_key: "$DEPLOYGATE_API_KEY"
    - deploy-to-bitrise-io@1.4.1: {}
    - cache-push@2.2.0: {}
    - slack@3.1.2:
        inputs:
        - webhook_url: "$SLACK_URL"

app:
  envs:
  - opts:
      is_expand: false
    PROJECT_LOCATION: "."
  - opts:
      is_expand: false
    MODULE: app
  - opts:
      is_expand: false
    VARIANT: ''
trigger_map:
- push_branch: master
  workflow: debug-deploy

ビルド作業を60％速く

ビルド作業を60％速く：

Force Xcode to use cashing! 

新しいステップを使って、Xcodeビルドを最大60％速くしよう！

exportコマンドを実行する場合を除き、Xcodeはすべてのビルド関連のキャッシュファイルとその他のデータをderived dataフォルダー（〜/ Library / Developer / Xcode / DerivedData）に保存して使用します。しかし、Xcodeのキャッシュはプロジェクトの形とファイルの変更時刻、内容などのすべてのプロパティに依存するため、このパスをキャッシュすることだけが必要なわけではありません。

 

ビルドのためにBitriseにリポジトリをクローンすると、すべてのファイルの修正時刻は現在の時刻（git cloneの時刻）に設定されるので、すべてのファイルは新しいビルドごとに変更されたとみなされます。内容はビルド間で変わりません。

 

ファイルの修正時間が変更されないように、Recursive Touch for Cacheという新しいステップを作成しました。

2 inputs:

  1. a path for a directory　 ディレクトリのパス　(by default: “$BITRISE_SOURCE_DIR”)
  2. a time　時間　 (by default: “2017–09–01T15:00:00+00:00”) input field

 

このステップでは、指定されたディレクトリの下にあるすべてのファイル変更時刻が設定されるため、開始した後のビルドでもファイルの変更時刻は同じになります。

 

セットアップ

適切なXcodeキャッシュを使用したい場合は、2つのステップを設定する必要があります。

  1. RecursiveTouch for Cacheステップ - ビルド間のプロジェクトファイルの修正時間を保存します。Xcode Unit Testステップの直前に行われるはずです。
  2. Cache：Pull、Cache：Push  - Derived dataパスをキャッシュします（下記のパスをCache：Pushステップのキャッシュパスに入力し、パス入力を省略します：〜/ Library / Developer / Xcode / DerivedData）

Proof

キャッシュが期待どおりに機能しているかどうか、どうやって確認できますか？

 

 

以下がログがキャッシュされる前の様子です。

 

 

 

次にこれがキャッシュが機能している時です。

 

=== BUILD TARGET ios-simple-objc OF PROJECT ios-simple-objc WITH CONFIGURATION Debug ===

Check dependencies

=== BUILD TARGET ios-simple-objcTests OF PROJECT ios-simple-objc WITH CONFIGURATION Debug ===

Check dependencies

** BUILD SUCCEEDED **

  

 

最後に、サンプルの構成例を見てみましょう。

 

  - activate-ssh-key@3.1.1:

      run_if: '{{getenv "SSH_RSA_PRIVATE_KEY" | ne ""}}'

  - git-clone: {}

  - cache-pull@1.0.0: {}

  - certificate-and-profile-installer: {}

  - recursive-touch: {}

  - xcode-test:

      title: 'Xcode: Unit Test'

      inputs:

      - simulator_device: iPhone 5s

      - output_tool: xcodebuild

  - cache-push@1.1.4:

      inputs:

      - cache_paths: "~/Library/Developer/Xcode/DerivedData"

      - ignore_check_on_paths: "~/Library/Developer/Xcode/DerivedData"

  before_run:

  after_run:

trigger_map:

- push_branch: "*"

workflow: primary




これらでderivedDataフォルダをキャッシュしてテストを実行したところ、ビルド時間が最大60％短縮されました。

 

注：アーカイブコマンドは常にクリーンなリ-ビルドを行うので、キャッシュを使用してもアーカイブを高速化することはできません。 （これはXcodeのバグです。）

 

 英語のブログ：

https://medium.com/@bitrise/60-faster-builds-force-xcode-to-use-caching-on-bitrise-af8979ca39a6 

はじめまして

 初めまして

 

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