メインコンテンツにジャンプ
チュートリアル

プルリクエストを実行可能なプレビューに変える

Stop waiting for TestFlight processing. Capgo PR previews let QA, PMs, and stakeholders test features on real devices in under a minute.

マーティン・ドナディュー

マーティン・ドナディュー

コンテンツマーケター

プルリクエストを実行可能なプレビューに変える

すべてのモバイル開発チームは、痛みを感じてきました:機能はレビュー用に完了しているが、ステークホルダーに届けるには、TestFlightまたはGoogle Playベータレビューの迷路をナビゲートする必要があります。何が分だけかかるべきものが、時間を要することになり、ベータビルドのインストールと管理に時間を費やします。

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

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

TestFlightの問題

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

  1. 開発者がPRを開く - 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 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 __CAPGO_KEEP_0__ setChannel() API

設定の準備 Capgo トークン

  1. あなたの Capgo ダッシュボード
  2. 設定 > API キーに移動してください
  3. __CAPGO_KEEP_0__ キーを生成する all 許可
  4. __CAPGO_KEEP_0__ CAPGO_TOKEN あなたの GitHub リポジトリのシークレットに追加してください

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

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

オプション 1: Shake メニュー (最も簡単)

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

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

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

自身の割り当て可能なチャンネルをすべて取得する

  1. チャンネルを検索して特定のPRを探す listChannels()
  2. 選択したチャンネルのアップデートをダウンロードする
  3. 「再読み込みする」/「後で」オプションでリロードを促す
  4. オプション2:カスタムチャンネルセレクターUI

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

- 自身の割り当て可能なチャンネルをすべて取得する

  • listChannels() - デバイスを選択したチャンネルに切り替える
  • setChannel() これらの基本ブロックを使用して、シンプルなUIを作成できます。
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;
}

Testers shake their device to open the debug menu, which shows a list of available channels with a search bar. They find their PR channel (e.g.,__CAPGO_KEEP_0__),

// 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 の場合、テストフライト/プレイストアの新しいビルドを配布する必要があります。PR のプレビューは、ネイティブ code を触らない JavaScript、CSS、資産の変更が最適です。

PR プレビューの利益者

QAエンジニア

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

プロダクトマネージャー

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

開発者

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

比較:Traditional vs PRプレビュー

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

ベスト プラクティス

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

PRプレビューの使用しない時

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

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

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

チャンネルサーフィングと組み合わせる

PRプレビューは、チャンネルサーフィングと組み合わせると最も効果的です。 チャンネルサーフィングあなたのアプリには次のことが可能です。

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

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

リソース

まとめ

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

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

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

続けて "Turn Every Pull Request Into an Installable Preview" から

あなたは「Turn Every Pull Request Into an Installable Preview」を使用している場合 Turn Every Pull Request Into an Installable Preview チャンネルルーティングとステージドロールアウトの計画に役立つ、 チャンネル チャンネル チャンネル チャンネル ベータテストソリューション ベータテストソリューション バージョン目標ソリューション バージョン目標ソリューション Written by __CAPGO_KEEP_0__

Capacitorアプリのリアルタイム更新

ウェブ層のバグが生じた場合、Capgoを使用して修正を配信し、数日間待つ必要のないアプリストアの承認を待つのではなく。ユーザーはバックグラウンドで更新を受け取り、ネイティブの変更は通常のレビュー経路で残る。

スタート

ブログの最新記事

Capgoは、プロフェッショナルなモバイルアプリを作成するために必要な最良の洞察を提供します。