Pull Requestを実行可能なプレビューに変える

すべてのモバイル開発チームは、痛みを感じています。機能はレビュー用に準備されていますが、ステークホルダーに届けるには、テストフライトまたはGoogle Playベータレビューの迷路を乗り越える必要があります。何が数分で完了するはずなのに、時間を費やし、ベータビルドをインストールし、管理することになります。

何があれば、プロダクションアプリがPull Requestから最新の変更を直接デバイスに取り込むことができ、再インストールやアプリストアの遅延なしで?

そのようなものが PR プレビュー 有効にする。開発者がPull Requestを開くと、GitHubアクションは専用のアップデートチャネルを作成し、変更を公開します。アプリをインストールしている人は、そのチャネルに切り替えて機能をテストし、元のアプリに戻ることができます。すべてのプロセスは、既存のアプリを離れずに実行できます。

TestFlightの問題

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

1. 開発者がPull Requestを開く - Codeのレビュー待ち
2. TestFlight待ち - 15-30分の処理時間
3. 検索とインストール - テスターが正しいビルドを探します
4. テストと繰り返し - すべての変更はまた待ち時間

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

PRプレビューのしくみ

PRプレビューはCapgoのチャンネルシステムを使用して、各PRごとのアップデートストリームを作成します。ここでは流れを説明します。

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

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

PRプレビューの設定

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

GitHub Actions Workflow

重要なのは .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 __CAPGO_KEEP_0__。 setChannel() APIトークンの設定

Capgoダッシュボードにアクセスしてください。

1. 設定>__CAPGO_KEEP_0__キーの設定 Capgo
2. API
3. 新しいキーを生成する all 権限
4. に追加する CAPGO_TOKEN あなたのGitHubリポジトリのシークレット

テスターがチャンネルを切り替える方法

テスターがPRチャンネルに切り替える方法は2つあります。

オプション1: Shake Menu (最も簡単な方法)

あなたのCapacitor設定でチャンネルセレクター付きのshakeメニューを有効にします。

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

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

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

1. Fetches all self-assignable channels via listChannels()
2. チャンネルを検索して特定のPRを表示します。
3. 選択後、更新をダウンロードします。
4. 「再読み込みする」/「後で」オプションの「再読み込みする」ダイアログを表示します。

オプション2: カスタムチャンネルセレクターUI

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

• listChannels() - 自分の割り当てを有効にしたチャンネルをすべて取得します。
• setChannel() - 選択したチャンネルにデバイスを切り替えます。

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チャンネルのクリーンアップ

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プレビューの利点

QAエンジニア

• PRを開くとすぐに機能をテストできます。
• 複数のPR間で切り替えられる
• 実機で修正とバグの検証が可能
• TestFlightの処理待ちがなくなりました。

製品マネージャー

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

開発者

• 変更に対して迅速なフィードバックを得る
• ステークホルダーに機能をデモする
• 特定のユーザーと問題をデバッグする
• ベータビルドの管理時間を削減する

比較:Traditional vs PR Previews

ベスト プラクティス

1. 名前を明確に表示する: 使用 pr-{number} 識別のための慣習
2. 自動クリーンアップ: PR が閉じたときにチャンネルを常に削除する
3. アクセスを制限する: デバッグ/ステージング ビルドでシェイク メニューを有効にする
4. プロセスを文書化する: PR テンプレートにテスト指示を追加する
5. 失敗を柔軟に処理する: チャンネル作成が成功する前にコメントを投稿する

PR プレビューの使用時期

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

• 新しい Capacitor プラグイン
• iOS native code changes
• iOS ネイティブ code 変更
• Android ネイティブ __CAPGO_KEEP_0__ 変更

ネイティブ ビルドに影響する依存関係の更新

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

PR プレビューは、チャンネルサーフィングと組み合わせると最も効果的です。 チャンネルサーフィングアプリは次の機能を持ちます。

• production - 全ユーザー向けの安定版リリース
• beta - オプトインユーザー向けの早期アクセス
• pr-123 - 特定のPR向けの機能プレビュー

プロダクションビルドのテスターは、インストール済みのアプリで任意のPRチャンネルに切り替え、機能をテストし、元のチャンネルに戻ることができます。

リソース

• Capgo Live Updates Documentation
• チャンネル Documentation
• Channel Surfing Guide
• CLI Commands Reference
• PR プレビュー ソリューション ページ

結論

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

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

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

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

Capgo を使用している場合 Turn Every Pull Request Into an Installable Preview を使用してチャネル ルーティングとステージド ロールアウトを計画する場合、Channels チャネル をCapgo のリリース チャネル機能名。ページ/エリア: Capgo のソリューション マーケティング ページ。ロール: 短い UI ラベルまたはナビゲーション アイテム。見られる場所: page solutions/white-label.astro。メッセージ キー `solutions_white_label_visual_cell2_value` (ソリューション ホワイト ラベル ビジュアル セル2 値)。 チャネルを参照してください。 チャンネルにおける実装詳細については チャンネル チャンネルにおける実装詳細については ベータテストソリューション チャンネルにおける製品ワークフローについて バージョン対象ソリューション 製品ワークフローについて