EAS Workflows とカスタムビルドでモバイル CI/CD を自動化する

EAS Build の登場当初、ビルドプロセスでカスタマイズできる範囲は eas.json が許すものに限られていた。特定のステップをスキップすることも、プロジェクト独自の実装に差し替えることもできなかった。build hooks は便利ではあったが、ビルドの前後に複雑な処理を組み込むには向いていなかった。

2023 年、私たちはカスタムビルド機能のプレビュー版をリリースした。開発者はビルドプロセスの一部を差し替えたり、まったく新しいビルドプロセスを一から書いたりできる。

こうした機能は現在、Expo の統合 CI/CD オーケストレーションシステムである EAS Workflows に取り込まれている。ビルド、テスト、送信、更新、通知を含むパイプライン全体を、1 つの YAML 設定で定義できる。

Expo は GitHub build triggers を非推奨とし、より強力で柔軟なオーケストレーションプラットフォームである EAS Workflows へ移行した。

.eas/build に置くカスタムビルドタスクの設定は、個々のビルドタスクをどう実行するかを決める。.eas/workflows に置く EAS Workflows の設定は、ビルドタスクを含む各タスクをどう組み合わせてパイプラインにするかを決める。

EAS Workflows でモバイル CI/CD パイプラインを組む

EAS Workflows は Expo の CI/CD オーケストレーションシステムで、YAML で定義したパイプラインがビルド、テスト、送信、更新、通知を自動化する。

Workflows はパイプラインをいつ実行するか、タスク同士がどう依存し合うかを決める。ビルドタスク（カスタムビルドタスクを含む）は、そのパイプラインのコンポーネントとして実行される。

Workflows は .eas/workflows/*.yml に定義し、次のトリガーに対応する:

push および pull request イベント
スケジュール実行
手動実行

これによりチームは、モバイルデリバリーのパイプライン全体を 1 つのシステムで自動化できる。

on:
  push:
    branches: ['main']
  pull_request:
    branches: ['main']
  schedule:
    cron: '0 2 * * 1-5'  # Weekdays at 2 AM UTC

どの workflow も eas workflow:run で手動実行でき、on: の設定に影響されない。パスフィルタやラベルベースのトリガー（pull_request_labeled）にも対応している。詳しくはトリガーのドキュメントを参照。

カスタムビルドのユースケース

ここ数か月、ユーザーが実際にどんな処理を動かしているかを聞いて回った。そうしたステップが EAS Workflows パイプラインの一部としてそのまま実行できるようになったことを嬉しく思う。いくつか例を挙げる:

ビルド完了後に Slack でチームに通知し、新しいビルドをダウンロードできることを知らせる（サンプル、ドキュメント）
Maestro のエンドツーエンドテストを実行する（サンプル、ドキュメント）
1 つのパイプラインで複数の target 向けにアーカイブを作成する。たとえば Android の本番アプリ（.aab）をビルドしつつ、テスト用のプレビュービルドも追加で生成する
ビルド成功後に TestFlight や Google Play へ自動で送信する（Android のサンプル、iOS のサンプル）
検証が通ったら OTA アップデートを配信する

これらのビルドタスクと自動化ステップは、EAS Workflows で組み合わせて 1 本のパイプラインにできる。

組み込みタスク: すぐに使える機能

カスタムビルドタスクに加えて、EAS Workflows にはモバイル CI/CD のよくあるシナリオ向けのタスクタイプが用意されている。カスタム設定は不要で、YAML でタスクタイプを宣言するだけでいい:

submit — ビルドを App Store または Google Play に送信する
testflight — TestFlight のグループに配信する。changelog と beta レビューの制御に対応
update — EAS Update で OTA アップデートを配信する
deploy — EAS Hosting で Web アプリをデプロイする
maestro / maestro-cloud — シミュレータ上で Maestro E2E テストを実行する
fingerprint — プロジェクトのネイティブな特徴をハッシュ化し、フルビルドが必要かを判断する
get-build — fingerprint に一致する既存のビルドを探し、重複ビルドを避ける
repack — ネイティブのフルリビルドなしで、既存のビルドに JS を約 2 分で再バンドルする
slack — webhook で Slack 通知を送る
github-comment — ビルドのリンクと QR コードを pull request に自動投稿する
require-approval — 手動承認で本番デプロイにゲートを設ける
doc — ワークフローのログに Markdown の説明を表示する

構文とサンプルの全体は組み込みタスクのドキュメントを参照。

ビルドをカスタマイズする方法

初期設定

ビルド profile の設定はを受け取り、.eas/build 配下にあるカスタムビルドタスクの設定を指定する。これらのカスタムビルドタスクは単体で実行することも、EAS Workflows パイプラインの一部として組み込むこともできる。

例を示す:

{
  "build": {
    "production": {
      // Builds with profile "production"
      // will use .eas/build/production.yml file
      "config": "production.yml" 
    },
    // You can also specify platform-specific workflows
    // by placing the property under platform-specific config.
    "development": {
      "android": {
        // uses .eas/build/development-android.yml
        "config": "development-android.yml"
      },
      "ios": {
        // uses .eas/build/development-ios.yml
        "config": "development-ios.yml" 
      }
    }
  }
}

カスタムビルドの基本フロー

最もシンプルな Custom Builds のフローは次のとおり:

build:
  steps:
    - eas/build

The 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: |
          # Post a new message to Discord
          # https://support.discord.com/hc/en-us/articles/228383668-Intro-to-Webhooks
          curl \
            -H 'Content-Type: application/json' \
            -d '{"content": "New build succeeded! URL: ${ eas.job.expoBuildUrl }"}' \
            https://discord.com/api/webhooks/... # your webhook URL here

run コマンドは Bash スクリプトとして実行される。curl、Fastlane、Node.js スクリプトなど、任意のカスタム自動化ロジックを使える。

これらのステップは、提出・テスト・通知といった他のタスクと一緒に、完全な EAS Workflows パイプラインへ組み込むこともできる。

カスタム JavaScript 関数

Bash スクリプトは単純なタスクに向いている。より複雑なタスクには JS 関数を書くことを勧める。

その利点は次のとおり:

型付きでビルドプロパティにアクセスできる
ワークフロー間で再利用しやすい
保守性が高い

カスタム関数は、カスタムビルドタスクにも、完全な EAS Workflows パイプラインにも組み込める。設定方法は EAS Build ドキュメントの「TypeScript functions」ガイドを参照。

カスタム eas/build

ビルドプロセスをより深くカスタマイズしたい場合は、単一の eas/build 関数を、その下にある個々のステップに置き換えられる。

これでできること:

暗号化された secrets を解除する
ビルド環境を変更する
依存関係を動的にインストールする
ビルド前に検証スクリプトを実行する

出発点として使える主なサンプルは 4 つ（2 プラットフォーム × 認証情報の有無）:

認証情報ありの Android（署名済み AAB をビルド）
認証情報なしの Android（Emulator APK をビルド）
認証情報ありの iOS（配布可能な IPA をビルド）
認証情報なしの iOS（Simulator APP をビルド）

コピーしたら、必要に応じて変更する。

たとえば、git-crypt で暗号化されたファイルを解除できる。そのためにはまず、base64 でエンコードした key を内容とする 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]  # Only runs if build succeeds
    params:
      build_id: ${{ needs.build.outputs.build_id }}

  notify:
    type: slack
    after: [build, submit]  # Runs regardless of success or failure
    params:
      webhook_url: https://hooks.slack.com/services/...
      message: 'Pipeline finished for ${{ needs.build.outputs.app_version }}'

needs は、そのタスクが依存先の成功時のみ実行されることを意味する。after は依存先の結果にかかわらず実行される——通知やクリーンアップに向いている。これでモバイルの CI/CD フローを完全に自動化できる。

旧版のビルド編成からの移行

既存のカスタムビルド設定はそのまま使い続けられ、Workflows パイプラインに直接つなぎ込める。すでに GitHub Actions や他の CI システムを使っているチームが現行の仕組みを捨てる必要はない——eas workflow:run を使えば既存のパイプラインから EAS Workflows を呼び出せる。iOS ビルド、コード署名、ストア提出といったモバイル固有のタスクは Workflows に任せ、lint、ユニットテスト、コードレビューは既存の CI が担い続けられる。

EAS サービスは次に何をするのか

プロジェクトをビルドするのは、質の高いモバイルアプリを届けるための一歩にすぎない。EAS Workflows は CI/CD 編成システム一式を提供し、チームが同じプラットフォーム上でビルド・テスト・提出・更新を自動化できるようにする。

EAS Workflows は CI/CD パイプラインのうちモバイル固有の部分——ビルド、コード署名、提出、OTA 更新——を、すべて Expo プロジェクト内で直接担う。

カスタムビルドタスクは今も重要で、こうしたパイプラインの中でビルドの挙動を深くカスタマイズできる。

私たちは EAS Workflows を拡張し続けており、新しいタスクタイプの追加、自動化能力の強化、連携の深化を通じて、チームがより速く、より確実に届けられるよう支援している。

ビルドと自動化のワークフローを進めるなかで、ぜひフィードバックを寄せてほしい。以下は良い次のステップだ:

本番環境へのデプロイワークフロー — フィンガープリント検出からストア提出までの完全なパイプライン
Maestro によるエンドツーエンドテスト — すべての PR でテストを実行する
プリパッケージタスクのリファレンス — すべてのタスクタイプの完全な構文
ワークフロー構文 — YAML の完全仕様