Pull Requestをインストール可能なプレビューに変える

すべてのモバイル開発チームは、痛みを感じています:機能はレビュー用に準備されていますが、ステークホルダーにそれを手に入れるには、TestFlightまたはGoogle Playベータレビューの迷路をナビゲートする必要があります。何が数分で時間を要することになります。待ち、インストール、ベータビルドの管理

あなたのプロダクションアプリが、任意のPull Requestから最新の変更を直接デバイスにプルすることができるようになったらどうですか? それが何らかの再インストールやアプリストアの遅延なしに?

それが PRプレビュー 可能です。開発者がPull Requestを開くと、GitHubアクションは、専用のアップデートチャネルを作成し、変更を公開します。アプリをすでにインストールしている人は、そのチャネルに切り替えて、機能をテストし、戻ることができます - すべてのアプリをすでに持っているので、外に出ることなく。

TestFlightの問題

モバイル機能のテストの伝統的なワークフローは、以下のようになっています:

開発者がPull Requestを開く - Codeはレビュー用に準備されています
TestFlightを待つ - 15-30 分の処理時間
見つけてインストール - テスターが適切なビルドを探します
テストを繰り返す - すべての変更はまた待ち時間

これはボトルネックを生み出します。QAはビルドを待ってブロックされます。製品マネージャーは機能を迅速に検証できません。開発者はフィードバックを待つ間、コンテキストを失います。業界はこの失われた生産性のコストを約 $340/PR で推定しています。

PR プレビューのしくみ

PR プレビューは Capgo のチャンネルシステムを使用して、PRごとに更新ストリームを作成します。ここでは流れを示します。

PR が開かれたり更新されたり - GitHub アクションがトリガーされます
バンドルがアップロードされる - ご自分のJS/CSSの変更はPR固有のチャンネルに流れます
投稿されたコメント - プルリクエストにテスターが指示を受ける
即時テスト - チャンネルを切り替え、テスト、切り替え

新しいアプリのインストールなし。テストフライトの遅延なし。同じプロダクションアプリは、異なるアップデートチャンネルからデータを取得できます。

PR プレビューの設定

PR プレビューを実装する前に、プロジェクトは Capgo Live Updates と設定する必要があります。すでに実行している場合は除きますが、 Capgo のクイックスタートガイドを参照してください。 Capgo Actions ワークフロー作成

GitHub Actions Workflow

__CAPGO_KEEP_0__ .github/workflows/pr-preview.yml:

name: PR Preview
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - name: Setup Bun
        uses: oven-sh/setup-bun@v2

      - name: Install Dependencies
        run: bun install

      - name: Build
        run: bun run build

      # Create a channel named after your PR (may already exist on synchronize)
      - name: Create PR Channel
        id: create_channel
        continue-on-error: true
        run: bunx @capgo/cli@latest channel add pr-${{ github.event.pull_request.number }} --self-assign
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}

      # Upload the build to that channel
      - name: Upload to Capgo
        run: bunx @capgo/cli@latest bundle upload --channel pr-${{ github.event.pull_request.number }}
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}

      # Post a comment with testing instructions (only on PR open)
      - name: Comment on PR
        if: github.event.action == 'opened'
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: ${{ github.event.pull_request.number }},
              body: '📱 **Test this PR on device:**\n\nOpen your app and switch to channel: `pr-${{ github.event.pull_request.number }}`\n\nUse the shake menu or call `setChannel()` from your app.'
            })

__CAPGO_KEEP_0__ --self-assign PRを作成する際にフラグを設定します。これにより、テスターはアプリ内からチャンネルに切り替えることができます。 setChannel() API。

Capgoの設定

__CAPGO_KEEP_0__ダッシュボードに移動してください。設定 > Capgo キーに移動してください。
API キーを生成します。
__CAPGO_KEEP_0__ の権限を付与します。 all __CAPGO_KEEP_0__ リポジトリのシークレットに追加します。
テスターがチャンネルに切り替える方法は2つあります。 CAPGO_TOKEN in your GitHub repository secrets

__CAPGO_KEEP_0__。

__CAPGO_KEEP_0__の設定

Capacitor の設定で shake メニューとチャンネルセレクターを有効にします:

// capacitor.config.ts
const config: CapacitorConfig = {
  // ... your other config
  plugins: {
    CapacitorUpdater: {
      shakeMenu: true,
      allowShakeChannelSelector: true
    }
  }
};

テスターはデバイスを振ってデバッグメニューを開き、利用可能なチャンネルのリストと検索バーが表示されます。彼らはPRチャンネル（例えば、）を探し、タップして選択し、自動的にアップデートをダウンロードして適用します。テストが終わったら、再びデバイスを振ってプロダクションに切り替えます。 pr-123shake メニューは自動で全てのフローを処理します:

すべての自分が割り当てられたチャンネルを取得する

チャンネルを表示して、特定のPRを検索する listChannels()
選択したチャンネルのアップデートをダウンロードする
「再起動する」/「後で」オプションでリロードを求める
Option 2: Custom Channel Selector UI

アプリ内にチャンネルSwitcherを組み込んで、利用可能なPRチャンネルをリストし、テスターが選択できるようにします。この機能は2つのAPIを使用します:

- 自分が割り当てられたチャンネルを取得する

listChannels() - 自分が割り当てられたチャンネルを取得する
setChannel() - __CAPGO_KEEP_0__を選択したチャンネルにデバイスを切り替えます。

import { CapacitorUpdater } from '@capgo/capacitor-updater';

// Get all available channels (including PR channels)
async function getAvailableChannels() {
  const { channels } = await CapacitorUpdater.listChannels();

  // Filter to show only PR channels
  const prChannels = channels.filter(c => c.name.startsWith('pr-'));

  return prChannels;
}

// Switch to a specific PR channel
async function switchToChannel(channelName: string) {
  await CapacitorUpdater.setChannel({
    channel: channelName,
    triggerAutoUpdate: true  // Immediately check for updates
  });
}

// Return to production
async function switchBackToProduction() {
  await CapacitorUpdater.unsetChannel({});
}

// Get current channel
async function getCurrentChannel() {
  const { channel } = await CapacitorUpdater.getChannel();
  return channel;
}

- これらの構築ブロックを使用して、シンプルなUIを作成できます。

// Example: List PR channels and let user select
const channels = await getAvailableChannels();
const current = await getCurrentChannel();

// Display channels in your UI
channels.forEach(channel => {
  console.log(`${channel.name} ${channel.name === current ? '(current)' : ''}`);
});

// When user selects a channel
await switchToChannel('pr-123');

- 完全なReactコンポーネントの例については、 - 以下の記事を参照してください。.

- チャンネル掃除

- PRがマージまたはクローズされたときは、チャンネルを消去したいと思います。別のワークフローを追加してください。

name: Cleanup PR Preview
on:
  pull_request:
    types: [closed]

jobs:
  cleanup:
    runs-on: ubuntu-latest
    steps:
      - name: Delete PR Channel
        run: bunx @capgo/cli@latest channel delete pr-${{ github.event.pull_request.number }}
        env:
          CAPGO_TOKEN: ${{ secrets.CAPGO_TOKEN }}

- このワークフローは、PRがクローズされたときにチャンネルを消去し、チャンネルリストをきれいに保つことができます。

- バージョン互換性

- PRプレビューは、JavaScriptバンドルがインストール済みのネイティブバージョンと互換性がある場合にのみ動作します。PRがネイティブcodeの変更 (新しいCapacitor プラグイン、iOS/Androidの変更) を含む場合、テスターは新しいネイティブビルドが必要になります。

- Capgoはバージョン互換性を自動的にチェックします。PRのバンドルがインストール済みのネイティブバージョンと異なる場合、更新は適用されません。この互換性のないcodeから起因するクラッシュを防ぐためです。

- PRがネイティブ変更を必要とする場合は、TestFlight/Play Storeの新しいビルドを配布する必要があります。PRプレビューは、ネイティブcodeに影響を与えないJavaScript、CSS、資産の変更が最適です。

- PRプレビューの利点

テストエンジニア

PRを開いたときに即時テスト
複数のPR間で切り替えられる
実機で修正とバグの確認
テストフライトの処理待たなくなる

製品マネージャ

機能をマージされる前にレビュー
PRに直接フィードバック
実装が要件に合っているか確認
レビューサイクル時間を短縮

開発者

変更に対するフィードバックが速くなる
Demo機能をステークホルダーに即時表示
特定のユーザーと問題をデバッグ
ベータビルドの管理時間を削減

比較:Traditional vs PR Previews

アスペクト	TestFlight/ベータ	Capgo PR プレビュー
ビルド時間	15-30分	1分未満
PR切替	5分以上再インストール	10秒
セットアップの複雑さ	App Storeの資格情報	1つのワークフローファイル
クリーンアップ	手動	自動
ネイティブcodeの変更	必要	(JSのみ)オプション

ベストプラクティス

チャンネル名を明確に: 使用 pr-{number} 変更の識別に便利な規則
自動クリーンアップ: PR がクローズされたときにチャネルを常に削除
アクセス制限: デバッグ/ステージングビルドでのシェイクメニューを有効にする
プロセスをドキュメント化: PR テンプレートにテストの指示を追加
失敗を柔軟に処理: チャネル作成が成功することを確認する前にコメントを投稿する

PR プレビューを使用しないとき

PR プレビューは JavaScript/CSS の変更用です。PR に含まれる場合

Capacitorの新しいプラグイン
iOSネイティブのcodeの変更
Androidネイティブのcodeの変更
ネイティブビルドに影響する依存関係の更新

それらの変更には、通常のTestFlight/Play Store配布が必要です。

Channel Surfingと組み合わせる

PRプレビューは、Channel Surfingと組み合わせることで最も効果的です。あなたのアプリには次のことが可能です。- 全ユーザー向けの安定版リリース

production - オプトインユーザー向けの早期アクセス
beta - 特定のPR向けの機能プレビュー
pr-123 __CAPGO_KEEP_0__プラグインの新しいもの

テスト用のビルドを持つテスターは、任意のPRチャネルに切り替え、機能をテストし、同じインストール済みアプリで戻ることができます。

リソース

結論

PRプレビューは、チームがモバイル機能をレビューおよびテストする方法を変える。TestFlightの処理待ちや複数のベータビルドの管理をせずに、既存のインストール済みアプリを使用して、任意のPRチャネルに秒単位で切り替えることができます。

セットアップは最小限です - 1つのGitHub Actions ワークフローファイル - そして、チーム全体に利益が積み重なることになります。QAはブロックされず、プロダクトマネージャーは迅速にレビューし、開発者は迅速なフィードバックを受け取ります。

最初にワークフローを 1 つのリポジトリに追加し、レビュープロセスがどのように変化するかを確認してみましょう。

Turn Every Pull Request Into an Installable Preview から続けてください。

あなたが使用している場合 プルリクエストをインストール可能なプレビューに変える チャンネルルーティングとステージドロールアウトを計画するには、CloudflareとCapacitorを接続します。チャンネルチャンネルチャンネルチャンネルベータテストソリューションベータテストソリューションの製品ワークフローバージョン目標ソリューション __CAPGO_KEEP_0__ __CAPGO_KEEP_0__ バージョン目標ソリューションにおける製品ワークフローについて。

インストール可能なプレビューにすべてのプルリクエストを変える