This documentation is available as Markdown for AI agents and LLMs. See the full Markdown index or append .md to any documentation URL.
EAS Workflows で本番デプロイを自動化する
ページを編集
EAS Workflows を使って、リリースブランチから Android と iOS の本番ビルドと無線経由のアップデートを自動化する方法を学びます。
本番向けの変更の多くが TypeScript/JavaScript のみであることを考えると、変更のたびにアプリを再ビルドするのは無駄が多いやり方です。
この章で学べること
mainへのプッシュのたびではなく、release/*ブランチから本番デプロイをトリガーする- プロジェクトのフィンガープリントに応じて、ネイティブビルドと OTA アップデートを使い分ける
- 本番ワークフローの後続ステップとして、アプリストアへの提出を自動化する
1 件
1 件
EAS CLI は、あるプロファイルで初めてビルドをトリガーしたときに認証情報の生成を促します。ワークフローが走る前に認証情報が用意されているよう、Android と iOS の両方で本番ビルドを手動でトリガーしておきます。
- eas build --profile production --platform allリリースブランチを使う
開発ビルドの章では、on.push.branches トリガーを使うと、指定した main ブランチへのプッシュのたびにワークフローが実行されることを見てきました。本番デプロイの場合、main ブランチへのプッシュのたびにワークフローをトリガーするということは、マージされた変更がすべて新しいリリースになるということです。多くのチームは意図的なリリースプロセスを求めるため、代わりにリリースブランチやタグを使います。
リリースブランチ戦略では、通常 release/* のようなパターンでブランチを指定します。* の部分は機能名やバージョン名です。これが継続的インテグレーション（CI）と継続的デリバリー（CD）を分ける境目になります。CI は main ブランチへのプッシュのたびに実行され、CD はチームが本番へデプロイする準備が整ったときにリリースブランチで実行されます。
次の表は、各ワークフローのトリガーがその役割をどう定めているかを示しています。
| ワークフローファイル | トリガー | ビルドプロファイル | 役割 |
|---|---|---|---|
| .eas/workflows/build.yml | on.push.branches: ['main'] | development | main ブランチへのプッシュのたびに実行される CI ワークフローです。ユニットテストの実行や開発ビルドの作成を行えます。 |
| .eas/workflows/preview.yml | on.push.branches: ['main'] | preview | main ブランチへのプッシュのたびに実行されるプレビューワークフローです。内部テストや関係者への共有のためのプレビュービルドを作成できます。 |
| .eas/workflows/production.yml | on.push.branches: ['release/*'] | production | リリースブランチへのプッシュのたびに実行される CD ワークフローです。 |
これらのファイルは、プロジェクトの GitHub リポジトリ内で衝突することなく共存できます。それぞれが異なるビルドプロファイルとトリガーを使っているためです。
本番ビルド向けの build ジョブタイプ
まずは本番ワークフローを作成することから始めましょう。EAS Workflows の事前パッケージ済みの build ジョブタイプを使い、Android と iOS の両方で実行します。
1
production.yml を追加する
.eas/workflows/ の中に、eas.json の production ビルドプロファイルを使う production.yml という新しいファイルを作成します。
name: Deploy to production on: push: branches: ['release/*'] jobs: build_android: name: Build Android type: build params: platform: android profile: production build_ios: name: Build iOS type: build params: platform: ios profile: production
これにより、release/* のパターンに一致するブランチへプッシュしたときに、Android 向けの .aab アーティファクトと iOS 向けの .ipa アーティファクトが作成されます。
2
ワークフローにフィンガープリントを追加する
ネイティブコードに変更があるかどうかを確認するために、ワークフローに fingerprint ジョブを追加し、それに応じて既存の build_android と build_ios のジョブを更新しましょう。あわせて、Android と iOS の既存のビルドを探すための get-build ジョブも追加します。
production.yml ファイルを次のコードで更新します。
name: Deploy to production on: push: branches: ['release/*'] jobs: fingerprint: name: Fingerprint type: fingerprint environment: production get_android_build: name: Check for existing Android build needs: [fingerprint] type: get-build params: fingerprint_hash: ${{ needs.fingerprint.outputs.android_fingerprint_hash }} profile: production get_ios_build: name: Check for existing iOS build needs: [fingerprint] type: get-build params: fingerprint_hash: ${{ needs.fingerprint.outputs.ios_fingerprint_hash }} profile: production build_android: name: Build Android needs: [get_android_build] if: ${{ !needs.get_android_build.outputs.build_id }} type: build params: platform: android profile: production build_ios: name: Build iOS needs: [get_ios_build] if: ${{ !needs.get_ios_build.outputs.build_id }} type: build params: platform: ios profile: production
上のワークフローでは、まず fingerprint ジョブが実行され、コードベースの変更に基づいたハッシュを生成します。続いて get-build ジョブが、同じフィンガープリントのハッシュを持つ Android と iOS の既存のビルドがあるかどうかを確認します。既存のビルドがなければ、build ジョブが実行されて本番向けの新しいビルドを作成します。
fingerprint ジョブの environment フィールドは、フィンガープリントを計算するときにどの環境変数を読み込むかを EAS に伝えます。本番環境では API_URL や機能フラグといった変数の値が異なることがあります。EAS がそれらの値をビルドに埋め込むと、ネイティブの層にも影響が及びます。environment: production を指定しておけば、フィンガープリントが実際に出荷される内容を反映できます。
build_android と build_ios のジョブで使っている if フィールドは、真偽値の式です。false と評価された場合、ビルドジョブはスキップされます。! 演算子によって、get-build が一致するビルドを見つけられなかったときにだけビルドジョブが実行されます。
3
アップデート用のジョブを追加する
現時点のワークフローは、ネイティブコードに変更があったときにのみ本番ビルドを作成します。TypeScript/JavaScript のファイルだけが変更された場合は、ネイティブビルドの代わりに OTA アップデートをトリガーしたいところです。
ネイティブコードに変更がないときに実行され、update ジョブタイプで OTA アップデートをトリガーする update_android と update_ios の 2 つのジョブを追加しましょう。
name: Deploy to production on: push: branches: ['release/*'] jobs: fingerprint: # ... get_android_build: # ... get_ios_build: # ... build_android: # ... build_ios: # ... update_android: name: Publish Android update needs: [get_android_build] if: ${{ needs.get_android_build.outputs.build_id }} type: update params: branch: production platform: android update_ios: name: Publish iOS update needs: [get_ios_build] if: ${{ needs.get_ios_build.outputs.build_id }} type: update params: branch: production platform: ios
このワークフローが行うのは、本番向けのアプリバイナリの作成か、OTA アップデートの公開だけです。ストアへの提出の自動化は、この次によく行われるステップで、下のアプリストアへの提出を自動化するセクションで説明します。
4
リリースブランチを作成して変更をプッシュする
注： この時点で、ワークフローファイルがすでに GitHub リポジトリに含まれていてmainブランチから参照できることを確認してください。
ワークフローをテストするために、リリースブランチを作成してターミナルウィンドウから GitHub リポジトリへプッシュしましょう。
- git checkout -b release/1.0.0- git push origin release/1.0.0EAS ダッシュボードを開いて、このワークフローの実行を探します。このフィンガープリントに対応するビルドはまだ存在しないので、build ジョブが実行され、update ジョブはグレーアウトされているはずです。
Android と iOS のビルドは並列に実行されます。各ジョブが完了すると、Android と iOS の新しいアーティファクトが手に入ります。
次に、同じリリースブランチでサンプルプロジェクトに TypeScript/JavaScript のみの変更を加えて、次のコマンドで再度プッシュしてみましょう。
- git add .- git commit -m "Update welcome text"- git push origin release/1.0.0ワークフローが実行されたら、EAS ダッシュボードで、フィンガープリントが前回のプッシュのビルドと一致していることを確認しましょう。build ジョブは完全にスキップされ、update ジョブが OTA アップデートを公開します。
アプリストアへの提出を自動化する
この章で作ってきたワークフローは、本番向けのアプリバイナリを作成するか、既存の本番アプリへ OTA アップデートを公開するだけのものです。ストアへの提出の自動化は、本番リリースのワークフローでこの次によく行われるステップです。
EAS Workflows は、アプリストアへの提出を自動化するための事前パッケージ済み submit ジョブを提供しています。使用するには、アプリストアの認証情報を EAS CLI で管理する必要があります。また、最初の Android リリース（.aab）を Google Play Store に手動でアップロードするなど、アプリストア側の要件も満たしておく必要があります。iOS には、Apple Developer Program への登録と署名用の認証情報の設定という、iOS 独自の準備があります。
アプリストア側の要件が整ったら、build ジョブのあとに実行される submit_android と submit_ios の 2 つのジョブをワークフローに追加できます。
# rest of the workflow file submit_android: name: Submit Android needs: [build_android] type: submit params: build_id: ${{ needs.build_android.outputs.build_id }} submit_ios: name: Submit iOS needs: [build_ios] type: submit params: build_id: ${{ needs.build_ios.outputs.build_id }}
上の submit_android と submit_ios のジョブは、どのビルドをアプリストアに提出するかを知るために build_id パラメーターを必要とします。これらは build_android と build_ios のジョブが実行されたとき、つまり新しい本番ビルドが作成されたときにのみ実行されます。TypeScript/JavaScript のファイルだけが変更された場合は新しいビルドが作成されないため、submit ジョブも同様にスキップされます。
まとめ
第 5 章：本番デプロイ
リリースブランチへのプッシュでトリガーされる Android と iOS の本番ワークフローを作成し、フィンガープリントでネイティブビルドと OTA アップデートを使い分け、EAS Submit がアプリストアへの提出をどう自動化するかを確認しました。
次の章では、本番デプロイをリリースブランチからバージョンタグへ切り替える方法を学びます。