EAS Workflows を使用すると、単一の YAML ファイルでビルド、テスト、アップデート、その他の処理を自動化できます。すぐに使える機能と、必要に応じたカスタマイズ方法について学びましょう。
EAS Workflows によるモバイル CI/CD パイプラインの統合
EAS Build の開始以来、ビルドプロセスのカスタマイズは eas.json で許可されている内容に限定されていました。一部のステップをスキップしたり、プロジェクト固有の処理に置き換える方法はありませんでした。さらに、ビルドフックは役立ちましたが、ビルドの前後で高度なワークフローを調整するには最も便利な方法ではありませんでした。
2023年に、開発者がビルドプロセスの一部を置き換えたり、完全に新しいビルドプロセスを作成できる完全にカスタマイズ可能なビルド機能のプレビューをリリースしました。現在、これらの機能は Expo の統合 CI/CD オーケストレーションシステムである EAS Workflows の一部となっています。
EAS Workflows を使用すると、単一の YAML 設定でビルド、テスト、サブミッション、アップデート、通知を含む完全なパイプラインを定義できます。
Expo は EAS Workflows を支持して GitHub ビルドトリガーを非推奨にしました。EAS Workflows はより強力で柔軟なオーケストレーションプラットフォームを提供します。
.eas/build のカスタムビルドジョブ設定は、個々のビルドジョブの実行方法を定義します.eas/workflows の EAS Workflows 設定は、ビルドジョブを含むジョブを完全なパイプラインに統合する方法を定義します
EAS Workflows によるモバイル CI/CD パイプラインのオーケストレーション
EAS Workflows は、YAML で定義されたパイプラインを使用してビルド、テスト、サブミッション、アップデート、通知を自動化できる Expo の CI/CD オーケストレーションシステムです。
ワークフローは、パイプラインがいつ実行され、ジョブがどのように相互に依存するかを定義します。カスタムビルドジョブを含むビルドジョブは、これらのパイプライン内のコンポーネントとして実行されます。
ワークフローは .eas/workflows/*.yml で定義され、以下のトリガーをサポートします：
- push および pull request イベント
- スケジュール実行
- 手動実行
これにより、チームは単一のシステムでモバイル配信パイプライン全体を自動化できます。
on:
push:
branches: ['main']
pull_request:
branches: ['main']
schedule:
cron: '0 2 * * 1-5'
on: 設定に関係なく、任意のワークフローは eas workflow:run で手動実行することもできます。
パスフィルタリングとラベルベースのトリガー（pull_request_labeled）もサポートされています。詳細はトリガーのドキュメントをご覧ください。
カスタマイズ可能なビルドのユースケース
過去数ヶ月間、ユーザーが実行している内容について話し合い、それらのステップを EAS Workflows パイプラインの一部として実行できるようになったことを嬉しく思います。以下にいくつかの例を示します：
- ビルド完了後にチームに Slack メッセージを送信し、ダウンロード可能な新しいビルドがあることを通知する（例、ドキュメント）
- Maestro エンドツーエンドテストの実行（例、ドキュメント）
- 単一のパイプラインで複数のターゲット用のアーカイブを作成する。例：Android 本番アプリ（.aab）をビルドしながら、テスト用のプレビュービルドも生成
- 成功したビルド後に TestFlight や Google Play に自動的にサブミット（Android の例、iOS の例）
- 成功した検証後にオーバーザエアアップデートを公開
これらのビルドジョブと自動化ステップは、EAS Workflows オーケストレーションを使用して完全なパイプラインに構成できます。
事前パッケージ化されたジョブ：すぐに使える機能
カスタムビルドジョブに加えて、EAS Workflows は一般的なモバイル CI/CD タスク用の事前パッケージ化されたジョブタイプを提供します。これらはカスタム設定を必要とせず、YAML でジョブタイプを宣言するだけです：
- submit — App Store や Google Play にビルドをサブミット
- testflight — 変更ログとベータレビュー制御を使用して TestFlight グループに配布
- update — EAS Update 経由で OTA アップデートを公開
- deploy — EAS Hosting 経由で Web アプリをデプロイ
- maestro / maestro-cloud — エミュレーターとシミュレーターで Maestro E2E テストを実行
- fingerprint — プロジェクトのネイティブ特性をハッシュ化して、フルビルドが必要な時期を検出
- get-build — フィンガープリントに一致する既存のビルドを検索し、冗長なビルドを回避
- repack — フルネイティブリビルドの代わりに、既存のビルドに JS を約2分で再パッケージ
- slack — webhook 経由で Slack 通知を送信
- github-comment — プルリクエストにビルドリンクと QR コードを自動投稿
- require-approval — 手動承認の後ろに本番デプロイをゲート
- doc — ワークフローログに Markdown ノートを表示
完全な構文と例については、事前パッケージ化されたジョブのドキュメントをご覧ください。
ビルドをカスタマイズする方法
初期設定
ビルドプロファイル設定は、.eas/build の下にあるカスタムビルドジョブ設定を指定する config を受け入れます。これらのカスタムビルドジョブは、独立して実行することも、EAS Workflows パイプラインの一部として統合することもできます。
以下に例を示します：
{
"build": {
"production": {
"config": "production.yml"
},
"development": {
"android": {
"config": "development-android.yml"
},
"ios": {
"config": "development-ios.yml"
}
}
}
}
基本的なカスタムビルドワークフロー
最もシンプルなカスタムビルドワークフローは以下のようになります：
build:
steps:
- eas/build
eas/build 関数は、設定されたビルドプロファイルを使用してアプリをビルドします。このステップは、テスト、サブミッション、デプロイメントジョブと並んで、より大きな EAS Workflows パイプラインの一部として統合することもできます。
Bash ステップ
ビルドが成功したら Discord にメッセージを送信する別のステップを追加してみましょう。Slack については、EAS Workflows に組み込みの slack ジョブタイプがあるため、カスタムスクリプトは不要です。以下に示す run ステップは、Discord や Microsoft Teams など、組み込みサポートのないサービスに役立ちます。
まず、Discord webhook を設定します。この Discord チュートリアルに従ってください。
webhook URL を取得したら、フローに run ステップを追加できます：
build:
steps:
- eas/build
- run:
command: |
# Discord に新しいメッセージを投稿
# https://support.discord.com/hc/en-us/articles/228383668-Intro-to-Webhooks
curl \
-H 'Content-Type: application/json' \
-d '{"content": "新しいビルドが成功しました！URL: ${eas.job.expoBuildUrl}"}' \
https://discord.com/api/webhooks/... # ここにあなたの webhook URL
run コマンドは Bash スクリプトとして実行されます。curl、Fastlane、Node.js スクリプト、または任意のカスタム自動化ロジックなどのツールを使用できます。これらのステップは、サブミッション、テスト、通知などの他のジョブと並んで、完全な EAS Workflows パイプラインに統合することもできます。
カスタム JavaScript 関数
Bash スクリプトは簡単なタスクには最適です。高度なタスクには JS 関数を書くことをお勧めします。これにより以下が提供されます：
- ビルドプロパティへの型付きアクセス
- ワークフロー間でのより良い再利用
- 保守性の向上
カスタム関数は、カスタムビルドジョブと完全な EAS Workflows パイプラインの両方に統合できます。
設定方法については、EAS Build ドキュメントの「TypeScript 関数」ガイドをご覧ください。
eas/build のカスタマイズ
ビルドプロセスのより深いカスタマイズが必要な場合は、単一の eas/build 関数をその基盤となるステップに置き換えることができます。これにより以下が可能になります：
- 暗号化されたシークレットのロック解除
- ビルド環境の変更
- 依存関係の動的インストール
- ビルド前の検証スクリプトの実行
足場として使用できる4つの主要な例があります（2つのプラットフォーム × 認証情報の有無）：
- 認証情報ありの Android（署名された AAB をビルド）
- 認証情報なしの Android（エミュレーター APK をビルド）
- 認証情報ありの iOS（配布可能な IPA をビルド）
- 認証情報なしの iOS（シミュレーター APP をビルド）
コピーしたら、必要な変更を適用します。例えば、git-crypt で暗号化されたファイルをロック解除できます。そのためには、まず base64 エンコードされたキーを含む GIT_CRYPT_KEY シークレットを EAS プロジェクトに追加します。
ロック解除された環境で実行することで、クリップボードにコピーできます。
次に、プロジェクトが Full Git Workflow 用に設定されていることを確認します（eas.json で cli.requireCommit を true に設定する必要があります）。
その後、eas/checkout ステップの後に以下の Bash スクリプトを追加する準備が整います。
EAS Workflows 内でのカスタムビルドジョブの使用
EAS Workflows を使用すると、ビルドジョブをコンポーネントとして使用して完全なパイプラインを統合できます。
例：
name: Build and Submit
on:
push:
branches: [main]
jobs:
build:
type: build
params:
platform: ios
profile: production
submit:
type: submit
needs: [build]
params:
build_id: ${{ needs.build.outputs.build_id }}
notify:
type: slack
after: [build, submit]
params:
webhook_url: https://hooks.slack.com/services/...
message: 'パイプラインが完了しました ${{ needs.build.outputs.app_version }}'
needs は、依存関係が成功した場合のみジョブが実行されることを意味しますafter は、成功・失敗に関係なくジョブが実行されることを意味し、通知やクリーンアップに役立ちます
これにより、モバイル CI/CD プロセスの完全な自動化が可能になります。
レガシービルドオーケストレーションからの移行
既存のカスタムビルド設定は引き続き動作し、Workflows パイプラインに直接統合されます。GitHub Actions や他の CI システムをすでに使用しているチームは、それらを放棄する必要はありません。eas workflow:run で既存のパイプラインから EAS Workflows を呼び出すことができ、Workflows に iOS ビルド、コード署名、ストアサブミッションなどのモバイル固有のジョブを処理させながら、現在の CI でリンティング、ユニットテスト、コードレビューを処理できます。
EAS サービスの今後の展開
プロジェクトのビルドは、高品質なモバイルアプリケーションを提供するための一歩に過ぎません。EAS Workflows は、チームが単一のプラットフォームでビルド、テスト、サブミッション、アップデートを自動化できる完全な CI/CD オーケストレーションシステムを提供します。
EAS Workflows は、CI/CD パイプラインのモバイル固有の部分（ビルド、コード署名、サブミッション、OTA アップデート）を Expo プロジェクト内で直接処理します。カスタムビルドジョブは、これらのパイプライン内でビルド動作の深いカスタマイズを可能にすることで、引き続き重要な役割を果たします。
新しいジョブタイプ、改善された自動化機能、より深い統合により EAS Workflows を拡張し続け、チームがより速く、より信頼性高く出荷できるよう支援しています。
ワークフローを構築・自動化する際のフィードバックをお待ちしています。以下に良い次のステップを示します：