React Nativeアプリのリリースは、最初の頃は手作業で行っていました。
- ローカルでビルド
- App Store Connect / Google Play Consoleへアップロード
作業自体は難しくありませんが、人によって実行環境が違ったり、手順漏れが起きたりすることがありました。
そこで、GitHub ActionsとFastlaneを組み合わせてデプロイを自動化しました。
今回は、その構成と導入して感じたことを紹介します。
構成
デプロイの流れはシンプルです。
GitHub Actions
│
▼
Self-hosted Runner
│
▼
Fastlane
│
┌──────┴──────┐
▼ ▼
App Store Google Play
Connect Console
GitHub ActionsからSelf-hosted Runner上でFastlaneを実行し、iOS・Androidをそれぞれストアへアップロードしています。
GitHub Actions
Workflowでは、リポジトリをチェックアウトし、必要な依存関係をインストールした後にFastlaneを実行します。
- uses: actions/checkout@v4
- name: Install dependencies
run: npm ci
- name: Deploy Android
run: bundle exec fastlane android deploy
iOSも同様にFastlaneのLaneを呼び出しています。
Fastlaneでデプロイ
GitHub Actions側には複雑な処理を書かず、デプロイ処理はFastlaneへまとめています。
例えばAndroidなら、
- AAB作成
- Google Playへのアップロード
を1つのLaneで実行しています。
lane :deploy do
gradle(
task: "bundle",
build_type: "Release"
)
upload_to_play_store
end
GitHub ActionsはFastlaneを呼ぶだけなので、Workflowをシンプルに保てます。
Secretの管理
ストアへアップロードするための認証情報はGitHub Secretsで管理しています。
例えば、
- Google Play Service Account
- App Store Connect API Key
- Keystore
- 証明書・Provisioning Profile
などです。
Workflowから環境変数として渡し、Fastlane側で利用しています。
認証情報をリポジトリへ含めなくて済むため、安全に管理できます。
導入して変わったこと
一番変わったのは、デプロイ作業が属人化しなくなったことです。
以前は、
- 実行する人のPC環境
- NodeやRubyのバージョン
- Fastlaneの設定
によって差が出ることがありました。
自動化後はRunner上で同じ環境が使われるため、誰が実行しても同じ結果になります。
また、リリース時に毎回コマンドを調べたり、手順書を確認したりすることもなくなりました。
Fastlaneを使って感じたこと
GitHub Actionsだけでもビルドはできますが、ストア公開まで考えるとFastlaneとの相性はかなり良いと感じました。
ビルドからアップロードまでを1つのLaneにまとめられるため、
- 処理が整理しやすい
- ローカルでもCIでも同じコマンドを使える
- GitHub ActionsのWorkflowがシンプルになる
というメリットがあります。
自動化で意識したこと
デプロイを自動化すると、人の作業は減ります。
その代わり、
- Secrets管理
- 失敗時のログ確認
- ロールバック方法
など、運用を考えた設計が重要になります。
自動化は「ボタンを減らす」ことではなく、「毎回同じ手順を確実に実行する仕組み」を作ることだと感じました。
まとめ
GitHub ActionsとFastlaneを組み合わせることで、
- デプロイ作業の自動化
- 実行環境の統一
- 属人化の解消
を実現できました。
React Nativeアプリでは、GitHub Actionsだけで完結させるよりも、Fastlaneにデプロイ処理を集約した方が構成が分かりやすく、保守もしやすいと感じています。