Expo が Hipcamp のネイティブおよび OTA 更新プロセスを効率化した方法

openaijamodel: gpt-5-mini-2025-08-07

ユーザー • React Native • プロダクト • 2025-12-09 • 読了時間: 7分

ゲスト投稿: Armaiz Adenwala、Tom Podlipni（両名とも Hipcamp のソフトウェアエンジニア）

この投稿では、Hipcamp が App Center の代替として Expo を採用し、ネイティブビルドを6倍高速化し、信頼できる OTA（over-the-air）更新を実現し、モバイルアプリにおいてウェブに近いリリース頻度を確立した経緯を紹介します。Armaiz はモバイルアプリ体験を担当し、Tom はCI/CD と開発ツール周りを担当しています。

背景

長年、Hipcamp はビルドとリリースに App Center を利用してきました。しかし Microsoft が App Center のサポート終了を発表したため、ネイティブビルドと OTA 更新を両方扱える代替が必要になりました。要件はシンプルでした:

iOS と Android の高速かつ信頼できるネイティブビルド
シームレスな OTA 更新機能
既存ワークフローへの容易な統合

複数の選択肢を評価した結果、Expo とそのクラウドサービスを採用しました。要件を満たしただけでなく、リリースプロセス全体を簡素化する機会も開きました。

Hipcamp について

Hipcamp は国立公園からブルーベリーファームまで、キャンプ場を発見して予約するための No.1 アプリです。私たちはプライベートな静かな場所、象徴的な公共の土地、設備の整ったキャンプ場など世界中のキャンプ選択肢を一つのアプリで提供しています。

今すぐダウンロード

Expo Build: 完全に最適化されたプロセス

最大の成果の一つはビルド速度でした。App Center のビルドは iOS で約60分かかり、タイムアウトが頻発して信頼性に欠けていました。Expo の Build サービスは一貫して約10分のビルドを実現し、開発サイクルを大幅に加速しました（6x 改善）。

ビルドプロセスの自動化

チームの使いやすさを高めるために、Expo の Build ワークフローをトリガーするカスタム yarn コマンドを作成しました。スクリプトは以下をプロンプトします:

環境（staging、production 等）
ビルドタイプ（QA vs. release candidate）
ビルドを説明する人間可読のメッセージ

プリチェックに合格すると、ワークフローは iOS と Android をビルドし、iOS を TestFlight に提出し、成功通知を送信します。他のビルド代替（例: GitHub Actions）と比べても、このワークフローは非常に簡単に作成できました。Expo のサービスはモバイルに特化しているため、ランナーは常に現在の SDK に最適化され、ほとんどのビルドの複雑さが抽象化されています。

Code Copy # .eas/workflows/builds.yml

build_android :
  name : Build Android
  type : build
  params :
    platform : android
build_ios :
  name : Build iOS
  type : build
  params :
    platform : ios
submit_ios_build :
  name : Submit iOS Build
  needs : [ build_ios ]
  type : submit
send_notification :
  name : Send Build Notification
  needs : [ build_android , build_ios , submit_ios_build ]
  steps :
    - name : Send Slack message
      run : |
        curl -X POST -H "Content-type: application/json" \
          --data '{...}' # Slack Webhook Call

ビルド完了時には、テストに必要な情報をすべて含めた通知を Slack チャンネルに自動投稿します:

TestFlight ビルド番号（iOS）
直接 APK ダウンロードリンク（Android）
該当ビルド用に事前フィルタされた Sentry エラー監視リンク
Slack と Asana の統合により、リアクションでそのビルド用のバグチケットを自動作成

このワークフローにより、組織内の誰でもレビューしてフィードバックを提供できるようになり、特定チームは QA と承認のための機能フィードを維持できます。

Expo Updates — 月次リリースから日次の OTA 更新へ

OTA 更新は私たちのモバイル開発ワークフローの中核になりました。App Store 審査は数日かかることがありますが、over-the-air updates を使えば、修正や新機能を即座に配信でき、チームがウェブでプロダクションにデプロイするのと同じ感覚で運用できます。

以前は AppCenter の CodePush を限定的にしか使っていませんでした。日常的なリリースに頼るには信頼性が足りなかったためです。Expo の OTA Update サービスはそれを変えました。安定的で予測可能、信頼しやすくなり、より頻繁に出荷できるようになりました。

リリースブランチ戦略

私たちは現在の本番状態を表す専用のリリースブランチを維持しています:

ネイティブリリースごとに新しいリリースブランチを切る
main ブランチに変更がマージされると、CI/CD パイプラインが自動的にその変更が OTA 可能か判定する
OTA 適格な変更はリリースブランチに cherry-pick され、Expo Updates 経由でデプロイされる

OTA 適格判定

expo-fingerprint を使って OTA 対応の変更を自動検出しています。このツールはネイティブ依存関係を深く分析し、固有のフィンガープリントを生成します。cherry-pick したコミットがリリースブランチと同じフィンガープリントであれば、ネイティブ変更がないことを意味し、安全に OTA 更新できます。

この自動化は非常に重要でした。OTA 適格性の判断での手作業チェックや人的ミスを排除できます。

OTA の流れ（概要）

パイプラインが OTA 更新を承認すると、カスタムスクリプトが以下を実行します:

Expo Upload に OTA をトリガー
Sentry の sourcemaps をアップロードし、更新 ID を使って新しいリリースを作成
モバイルアプリは自動的に Sentry を最新の Expo Update ID に向けるよう設定
GitHub のリリースとタグを更新し、当該リリースの Expo Update ダッシュボードや Sentry の issue への直接リンクを付与

OTA 更新がもたらした影響

このワークフローはモバイル機能の出し方を変えました:

ネイティブリリースの回数が減少
ウェブと同等のデプロイ頻度（モバイルリリースがウェブと同じペースに）
インシデント対応の高速化（壊れたデプロイを迅速に特定してロールバック可能）
ストレスの軽減（本番バグ修正のための緊急ネイティブリリースが稀になった）

結論

Expo の採用はチーム全体に波及効果を生みました。エンジニアはビルド問題のデバッグや遅いビルド待ちに費やす時間が減り、プロダクトマネージャーは機能が即座にプロダクションにデプロイされるのを見て迅速にイテレーションできます。デザイナーは自分のデバイスで非同期に機能を確認でき、オンコールのエンジニアはストア審査の緊急対応に追われることなく本番バグに対処できます。

EAS Builds はビルド時間を大幅に短縮し、Expo Updates はモバイルアプリにウェブのようなデプロイ速度を可能にしました。React Native プロジェクトで Expo を検討しているなら、私たちは自信を持って言えます: それは正しい選択でした。

外に出る人をもっと増やしたいですか？私たちと一緒に働きませんか。Join us at Hipcamp.

How Expo streamlined Hipcamp’s native and over-the-air update processes

要約

Summary

Key Points

翻訳

背景