Tech BLOG

SNS SHARE

【 GitHub Actions (Self-hosted runners) × Firebase App Distribution 】 iOS アプリの配布を自動化する

2021/04/09
技術開発 ソフトウェア開発
iOS エンジニア 伊藤 iOS エンジニア 伊藤


こんにちは、 iOS エンジニアの伊藤です。
今回は、 iOS アプリの配布を自動化を GitHub のサービス 『 GitHub Actions (Self-hosted runners) 』 と Google のサービス 『 Firebase App Distribution 』 を活用して行ったので、その情報を共有いたします。
 

自動化の経緯


Braveridge では、 BLE 製品の検査に iOS アプリを使用することが多々あります。
もちろん製品によって確認したい項目や、性能も違う為、製品の数だけアプリを作ることになります...

iOS アプリを配布するということは、 Provisioning Profile 作成/更新、アプリや証明書の有効期限、端末登録など管理することが多く大変です。
これからアプリがどんどん増えていくということは見えていますので、何も用意しなければとんでもない事になってしまうことが予想できます。

この課題は早めに解決しなくてはと思い 『 検査アプリ配布の自動化 』 をできるようにしました。
（ 検査アプリ作成の自動化 も鋭意作成中です。 )

今回の構成では、 GitHub の GUI で、タグを作成するとワークフローが動作し、 Firebase App Distribution に アップロードされ、 検査端末でアプリがダウンロードできるような仕組みになっています。
 

自動化の構成図

ci/cd_flow

選定サービス


自動化は業務の効率化に必須だと思っています。
ただ、自動化に振り回されてはいけないということは常に考えているので、なるべく小さく構成できるようにしています。
 

CI / CD GitHub Actions
ビルド fastlane
デプロイ先 Firebase App Distributon
通知 teams


iOS アプリの自動化といえば、 Bitrise や CircleCI などが、よく聞くサービスだと思います。
ただ、これらのサービスは、macOS でのビルドに関して、無料枠では制限が大きく、今回は選択を見送りました。

そこで、GitHub Actions の Self-hoted runners に目をつけています。
Self-hoted runners を利用すれば、使用していない Mac は必要にはなりますが、無料枠の制限を気にすることなく、ビルドと配布を行えます。

fastlane は、モバイルアプリビルドの自動化ツールです。
なんでも出来すぎるので、やりすぎないように注意しなければいけないところが難しいところです。

Firebase App Distributon は Firebase の機能の一つで、モバイルアプリの配布が出来るサービスです。
ただ現在、beta という表記のため、今後のことを考えると少し不安ではあります。
 

自動化の流れ

control_flow


実質、アプリ配布に必要なユーザーの作業は、 Git Push と タグ作成のみです。

ビルドに必要な firebase_token 等の環境変数設定や、証明書管理は、管理者(私)が手動で行っています。
この辺りも自動化できるところはコツコツやっていく予定です。
 

導入前に 〜 ① 自動化ファイルをリポジトリに追加する


管理者は、最終的に以下のファイルをリポジトリに追加していきます。
 

add files


 - /.github/workflows/my-workflow.yml
 - /fastlane 
　　- Appfile
　　- Fastfile
　　- Matchfile
　　- Pluginfile
　　- README.md
　　- report.xml
 - Gemfile
 - /{repo_name}/GoogleService-info.plist


必要な作業
 - ".bundle/" を .gitignore に追記。
 - match で作成された Procisioning Profile を設定。
 

導入前に 〜 ② fastlane match 用の準備


必要なものは、
 - Provisioning Profile、開発者証明書/秘密鍵 をアップロードしておく用の private repository
 - 証明書を扱うことのできる 管理者用 AppleID
 - （Provisioning Profileが作成できる開発者証明書/秘密鍵）　※ fastlane match の自動作成で成功する場合は必要なし

設定時の話ですが、もしも証明書でエラーになってしまう場合は、 Distribution鍵作成の上限になっている（最大 3個）になっていることが考えられます。
その為、既存の AppleDeveloper にて証明書を削除するか、 fastlane match import を使って、既存の開発者証明書/秘密鍵 を private repository にセットします。

shell


 # 証明書作成不可のエラーコード 
 Could not create another certificate, reached the maximum number of available certificates.

導入方法 〜 fastlane


まずは、 fastlane の設定です。
ポイントは、 以下の 3点です。

 - rbenv に切り替えておく
 - bundler でバージョンを管理する
 - fastlane match が動作するように、開発用 Mac に、開発者証明書/秘密鍵をインストールする
※ match を利用したくない場合は、 CI/CD用の Mac に直接 Provisioning Profile と 開発者証明書/秘密鍵 をインストールすれば良いと思います。


rbenv は、 ruby が予期せぬ動作をしないように導入しておきます。
 

shell

# rbenv のインストール
$ brew install rbenv ruby-build

# インストール可能なリスト
$ rbenv install -l

# 最新の安定版を指定して、 インストール
$ rbenv install 3.0.1

# 使用するバージョンを指定
$ rbenv global 3.0.1

# rbenv が動作するように記述を追加
$ touch ~/.bash_profile
$ echo '# rbenv' >> ~/.bash_profile
$ echo 'export PATH=~/.rbenv/bin:$PATH' >> ~/.bash_profile
$ echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
$ touch ~/.bashrc
$ source ~/.bash_profile


次からの作業は、証明書を作成/管理したい mac だけで良いです。
 
認証情報を管理する必要があるので、これからの作業は home ディレクトリでやると良いと思います。
（プロジェクトごとに fastlane 設定しても良いが、ログイン認証が都度になってしまうため。）
 
fastlane match を利用する為、  bundler と fastlane をインストールします。
 

shell


# home
$ cd ~

# bundler install
$ sudo gem install bundler

# fastlane install
$ sudo gem install fastlane --verbose


fastlane match をセットアップします。
 

shell


# fastlane match 有効化
$ fastlane match init


{user}/.fastlane/Matchfile が作成されているかと思いますので、
これを以下のように編集します。
 

Matchfile


git_url("{ 証明書アップロード用の GitHub リポジトリ }")
username("{ 証明書作成権限のある AppleID }")
storage_mode("git")
type("adhoc") 
team_id("{ developer_team_id }")
team_name("{ developer_team_name }")


そして証明書作成コマンドを打っていきます。
 

shell


# apple developer appid regiter
$ fastlane produce -a { app_identifier }

# apple developer provisioningProfile regiter
$ fastlane match adhoc

# app_identifier を聞かれるので、
# -> { app_identifier }


初めの起動時には、 GitHub と証明書の作成の為にログイン認証が入ると思います。
設定に問題がなければ、　{ match - Adhoc - { app_identifer } } の名前の Provisioning Profile が作成され、 設定を行ったリポジトリにアップロードされています。

作成した Provisioning Profile はプロジェクトに 『 manual sign 』 にしてセットしてから、 GitHub に Push しておきましょう。
 

導入方法 〜 Firebase App Distribution


最後に Firebase の設定です。
ポイントは、 以下の 3点です。

 - GoogleService-info.plist をプロジェクトに導入する ( pod install は特に必要なし )
 - プロジェクトが一つでも、複数の AppID を取得できるので、プロジェクトは一つでも良い
 - firebase login:ci でトークンを出力する
 


前提として、 Firebase のアカウントは作成済ということにさせてください。
 


はじめに、 配布用のプロジェクトを作成し、 iOS アプリを Firebase に登録してください。
続いて、ダウンロードした GoogleService-info.plist をリポジトリに追加します。
 

googleservice_info_add


追加した iOS アプリの App Distribution を有効化します。
リリースとモニタリング -> App Distribution を選択し、 開始を押してください。
 

app_distribution_start


有効化した後、 AppID を探しにいきます。
プロジェクト概要の右のギアアイコン -> プロジェクトを設定の中に、マイアプリ情報があります。

そこに記述されている アプリID が今回必要な FIREBASE_APPID になります。 
 

get_firebase_app_id
firebase_appId_console


最後に Firebase に自動でログインできるように、認証トークンを発行しておきます。
 

shell


$ firebase login:ci


自動でブラウザが開かれ、認証が行われると思います。
認証後、発行されたトークンがターミナルに表示されるので、リポジトリの FIREBASE_TOKEN へセットします。
 

導入方法 〜 GitHub Actions (Self-hosted runners)


次に、GitHub Actions の設定です。
ポイントは、 以下の2点です。

 - repository ではなく、 organization にて Self-hosted runners のマシンを設定する。（チームの場合）
 - secret を、repository ごとに設定する。
 


こちらも、CI/CD 用の MAC で操作していきます。

GitHub -> Organization -> Setting -> Actions と選択し、 Actions permissions の画面を表示します。
下部に、 Add New の緑のボタンがあるので選択し、 画面に表示された指示通り、 macOS と GitHub Actions を紐付けます。
 

github_actions_Self_hosted
github_actions_result


表記通りに進めれば、 『 Listening for Jobs 』 と表示されているはずです。
この状態でリポジトリを監視している状態となります。

監視状態は、mac をシャットダウン、 スリープになるまで動作します。
コマンドの control + C でも止めることが可能です。
 


次に secret を repository に追加します。
 

github_actions_add_secret


New repository secret から下記の様な、 secret をリポジトリごとに設定します。
 

APP_NAME scheme 名 & xcodeproj 名を設定
FIREBASE_APPID Firebase App Distribution から得られるアプリ用のID
FIREBASE_TOKEN firebase login:ci から得られる認証トークン
TEAMS_UPLOAD_URL teams 通知用の URL


GitHub GUI での設定項目は以上になります。

Self-hosted の設定は、各リポジトリに、マシンを紐づける場合は、毎回行う必要がある上に、
ターミナルを複数起動しておかなければならなくなってしまいます。
 
そのため、可能であれば、 organization で設定できると楽です。
 

実装ワークフローファイル


実際に使用したワークフローファイルを紹介いたします。

ワークフローの内容のポイントとしては、
 

  • タグを切った時にワークフローが動作するようにしている、 今回は ' FactoryDevelop_v* ' でタグを作成した時、 ワークフローが動作するようになっている
workflow.yml

on:
  push:
    tags:
      - 'FactoryDevelop_v*'
  • ワークフロー起動 OS を Self-hosted runners に指定している　（指定しないと、 容量が自動で使用されます...）
workflow.yml

jobs: 
　　build: 
　　　　runs-on: [self-hosted, macos, x64, iOS]
  •  cocoapods などを version 管理できるように bundle でインストールしている
workflow.yml


    - name: bundle Install
      run: bundle install --path .bundle

    - name: pod Install
      if: steps.cache-cocoapods.outputs.cache-hit != 'true'
      run: bundle exec pod install


こちらがワークフローファイルコードの全体です。
 

workflow.yml

name: Deploy to Firebase App Distribution

on:
  push:
    tags:
      - 'FactoryDevelop_v*'

jobs:
  build:
    runs-on: [self-hosted, macos, x64, iOS]

    steps:
    - uses: actions/checkout@v1
    - uses: actions/setup-node@v1
      with:
        node-version: '10.x'
    
    - name: show Xcode version
      run: xcodebuild -version

    - name: before cache
      run: |
        mkdir -p ~/pods/mod
        ls ~/pods
      
    - uses: actions/cache@v1
      id: cache-pods
      with:
        path: ~/pods/mod
        key: ${{ runner.os }}-pods-${{ hashFiles('**/Podfile.lock') }}
        restore-keys: |
          ${{ runner.os }}-pods-
    
    - name: npm Iinstall
      run: npm install -g firebase-tools

    - name: bundle Install
      run: bundle install --path .bundle

    - name: pod Install
      if: steps.cache-cocoapods.outputs.cache-hit != 'true'
      run: bundle exec pod install
     
    - name: adhoc
      env:
        FIREBASE_TOKEN: ${{ secrets.FIREBASE_TOKEN }}
        TEAMS_URL: ${{ secrets.TEAMS_UPLOAD_URL }}
        FIREBASE_APPID: ${{ secrets.FIREBASE_APPID }}
        APP_NAME: ${{ secrets.APP_NAME }}
      run: bundle exec fastlane upfirebase


fastlane の Fastfile も中身を書きすぎないように注意しています。

動作としては、version 取得 → Provisioning Profile 取得 → ビルド → firebase deploy → teams 通知 となっています。 

下の Fastfile ではテストの部分、ビルド番号を増分する箇所などは省いています。
 

Fastfile


default_platform(:ios)

platform :ios do

    lane :upfirebase do 
    app_version = get_version_number(xcodeproj: ENV["APP_NAME"] + ".xcodeproj", target: ENV["APP_NAME"])
    display_name = get_info_plist_value(path: ENV["APP_NAME"] + "/Info.plist", key: "CFBundleDisplayName")
    
    match(
        type: "adhoc", 
        readonly: is_ci
    )

    gym(
        scheme: ENV["APP_NAME"],
        configuration: "Debug",
        export_method: "ad-hoc"
    )
    
    firebase_app_distribution(
         app: ENV["FIREBASE_APPID"],
         testers: "[testuser@email]",
         release_notes: "test release",
         firebase_cli_path: `which firebase`.strip()
    )

    teams_url = ENV["TEAMS_URL"]
    teams(
        title: "GitHub Actions 終了",
        message: "アプリのアップロードが完了しました。",
        facts:[
            {
                "name"=>"Message",
                "value"=>"#{display_name}_v#{app_version} の配布が開始されました。"
            },
            {
                "name"=>"URL",
                "value"=>"https://appdistribution.firebase.google.com/testerapps"
            }
        ],
        teams_url: teams_url
    )
    end
  
  error do |lane, exception|
  end

end

実装してみて


やはり、アプリの作成から配布までのラグが大きく短縮されるのが良いです。

アプリをビルドする必要が出てくるとどうしても時間を取られがちです。
こういった自動化を組んで、ミスを少なく、確実に作業できる環境を整えていくのも大切な作業ですよね。
 

さいごに


世の中のサービスもたくさん増えてきて、選択するだけでも苦労することがあると思います。

そんな中でも、情報を発信してくれる先駆者の方々のおかげでとても助かっています。

この記事も、アプリ配布を自動化しようと思ってるけど...と困っている様な方々に届けば嬉しいです。

それでは次の更新まで ﾉｼ
 

参考


 ・ Documents
 　- fastlane documents
 　- Firebase documents
 　- GitHub Actions documents

 ・ blog
 　- rbenv 導入 ( Qiita )

 ・ 図作成
 　- diaframs.net
 

PREV

オリジナルデバイス製作に最適なIoTデバイス用樹脂ケースを販売開始しました！

NEXT

WebアプリケーションのCI/CD
最新記事
ARCHIVES

おすすめの記事

SNS SHARE