AppleのTestFlightアプリはAndroid用に存在しない。Androidでは、Google Play Consoleのテスト機能が最も近い公式の代替となる。 Google Play Consoleのテスト機能は、Google Play Storeで配布されるアプリのテストに使用される。 AppleのTestFlightモデルはiOS用に設計されており、最大100名の内部テスターと10,000名の外部テスターをサポートする。 外部ビルドの場合、AppleのTestFlightモデルではレビューが必要であり、レビューの時間は約__CAPGO_KEEP_0__ __CAPGO_KEEP_0__, __CAPGO_KEEP_0____CAPGO_KEEP_0__ 48 時間、および有効期限切れのビルドが作成される 90 日間.
iOS から移行したばかりの場合は、Android のリリースプロセスが奇妙に分散したように感じることがよくあります。iPhone の場合、「テストフライトで送信する」は明確な指示です。Android の場合、必要なものによっては、内部ビルドの高速ループ、管理されたパブリックベータ、またはリリース後に再度ストアを待たずにライブアプリを修正する方法が必要になります。
その違いは重要です。Android のベータテストは、単一のブランドアプリに焦点を当てていますが、実際には 配布パス。チームはすべてGoogle Play Console内に留まるかもしれませんが、他にはFirebase App Distributionを使用して、プレイトラックに触れる前にテスターへのハンドオフを高速化します。 Capacitor アプリを配信する場合、ベータツールが解決しない別の後リリースの問題が存在します:既に生産環境に存在するアプリに緊急のウェブアセット修正をプッシュすることです。
目次
- Android におけるテストフライトはありますか?
- Google Play Console のテストトラックの説明
- 迅速な開発のための Firebase App Distribution
- Android ベータ配布オプションの比較
- 伝統的なベータ配布の限界
- Beyond Beta Testing with Capgo Live Updates
- モダンなAndroidリリースワークフローを構築する
Android用のTestFlightはありますか?
いいえ。 AppleからAndroid用のTestFlightはネイティブではありません。TestFlightアプリのAndroid版を探している場合は、見つけることができません。Googleの第一パーティーなパスは Google Play Console、テストは 内部、クローズド、オープンテストトラック 、TestFlightスタイルの別個のアプリではなく、この AndroidのTestFlight代替.
の概要 この質問が繰り返し出る理由は歴史的であり、ユーザー間違いではありません。AppleがTestFlightを取得する前に、TestFlightはクロスプラットフォームツールでした。2013年5月までに、開発者はすでに サービスにアクセスする際、iOSとAndroidのワークフローを一つに統合する必要性が長い間存在していることを思い出させる便利なリマインダーです。TechCrunchがTestFlightのAndroid拡張を取り上げた記事で TechCrunchのTestFlightのAndroid拡張に関する記事.
実践的なルール: iOSでは「TestFlightアプリ」と考えてください。Androidでは「配布戦略」と考えてください。
この区別はリリースの計画に影響を与えます。Androidでは、Play管理トラック、直接テスターへの配布、またはエンジニアリングパイプラインの一部としてローカルまたはインストルメンテッドテストの選択肢があります。すべてのものに一つのフロントドアはありません。
チームがGoogleのデフォルト以外のツールの拡大マップを求めている場合、この モバイルアプリ配布代替品のリスト は便利な相談相手です。重要なリセットは簡単です: AndroidのTestFlightのクローンを探すのではなく、リリースステージに合ったAndroidのワークフローを選択してください。
Google Play Console Testing Tracksの説明
Google Play Consoleは、公式のAndroid版のベータ配布です。テスター用の「一つのアプリ」ではなく、「制御されたレーン」のセットです。リリースパイプラインの中にあります。より柔軟ですが、誰が何のビルドを受け取るか、そしてなぜを受け取るかを明確にする必要があります。
Googleのリリース哲学は、多くのチームが想像しているよりもテストに重点を置いています。Googleは、公表前に継続的にアプリテストを行うことが、 迅速なフィードバックを可能にする, 早期の失敗検出AppleのドキュメントページであるTestFlightの 現代のチームがプレリリーステストを構成する方法の対照Google Play Consoleのテストトラックの4つの段階を示すインフォグラフィック
Playトラックを理解する最も清潔な方法は、
信頼の円の中心に 内部テスト.
- エンジニア、QA、製品チームがビルドを迅速に検証するために使用する 閉鎖テスト
- 選択された外部ユーザーに拡大する。クライアントのステークホルダー、パイロットカスタマー、またはサポートを主導するベータグループを想像してください。 信頼の円の外側
- Open testing は、一般公開のベーターラインです。広範なフィードバックを受け取るために、より広いユーザー層にアプリを公開することを心配しないときに使用します。
- Production は、実際のリリースパスです。ベータトラックではありませんが、プロモーションをトラック間で行うことはリリースシステムの一部です。
This article on Google Play ステージドロールアウト は、テストトラックと合わせて読む価値があります。ロールアウトの制御とテストの Discipline は密接に関連しています。
How the tracks map to real release work
iOS チームがしばしば犯す間違いは、Android の 3 つのトラックをすべて「ベータ」として扱うことです。そうではありません。各トラックは、異なるオペレーショナル・プロブレムを解決するために使用されます。
Internal testing
Internal testing を使用するには、スピードが綺麗さよりも重要です。候補ビルドがあり、迅速な回答が必要です: ログインが機能するか、分析イベントが発生するか、リリースバリアントがデバッグバリアントと同じように動作するかなど。
This track is the closest Android analogue to a quick TestFlight handoff inside a company. It’s not for broad discovery. It’s for confidence before outsiders touch the app.
クローズドテスト
クローズドテストは、ほとんどのAndroidベータープログラムが時間を費やすべき場所です。アクセスを制御し、一般公衆のパスからアプリを外し、顧客タイプや機能の露出によってフィードバックをセグメント化できます。
クローズドテストは、次の場合にうまく機能します:
- 機密性が必要な場合: 企業のパイロット、パートナーのプレビュー、またはクライアントのために契約作業
- クリーンなフィードバックが必要な場合: 招待された小さなグループは、一般公衆のベータクロウドよりも明確な問題を報告することがよくあります。
- ビジネスワークフローを検証している場合: B2Bアプリ、フィールドアプリ、ヘルスケアワークフロー、内部企業ツールはここに該当します。
クローズドテストは、Androidチームが実世界の使用を実現するためにパブリックストアのノイズを避けるために、通常、甘いスポットです。
オープンテスト
オープンテストは、広範なデバイスカバレッジとより多様な使用パターンを実現したい場合に便利です。また、ユーザーがベータエクスペリエンスに参加していることを認識しているため、ソフトなリリースパスも作成されます。
__CAPGO_KEEP_0__は、早すぎるオープンテストを使用することは機能しません。
__CAPGO_KEEP_0__のクラッシュ率が安定していない場合、または__CAPGO_KEEP_0__のオンボーディングが毎日変更されている場合、または__CAPGO_KEEP_0__のサポートチームがIncomingレポートを受け付ける準備ができていない場合、オープンテストはインサイトではなく混乱を増幅します。
- __CAPGO_KEEP_1__の実践的な進行は次のようになります。 __CAPGO_KEEP_1__で始めます
- __CAPGO_KEEP_1__のリリース候補チェックのために。 __CAPGO_KEEP_2__に進めます
- __CAPGO_KEEP_2__の信頼できる外部検証のために。 __CAPGO_KEEP_3__に進めます
- __CAPGO_KEEP_3__が安定している場合にのみスケールを活用できます。 __CAPGO_KEEP_4__に進めます
__CAPGO_KEEP_4__のベータフィードバックがインクレメンタルなものではなく構造的なものである場合にのみ。
__CAPGO_KEEP_5__は、__CAPGO_KEEP_6__のアプリをより速く実行するために使用します。 Firebase App Distribution __CAPGO_KEEP_0__
https://firebase.google.com/docs/app-distribution
チームがまだPlayストアベータのための準備ができていない場合に、よく使用するオプションです。
Firebase App DistributionはPlayトラックよりも Firebase App Distributionは、次の場合に強みを持っています。.
速度
- 以下のケースでよく使用されます。 Playストアへのリリース前に、実際のリリースビルドをユーザーに配布したい場合
- CI/CDドライブされたテスト パイプラインはマージ、ブランチカット、リリース候補タグの後にビルドを生成して、テスターに配布します。
- 短いフィードバックループ: 内部テスターには、毎回候補者を出荷するたびに、より正式な登録パスが必要ありません。
通常、チームは直接性が好まれます。ビルドをアップロードし、テスターに共有し、フィードバックを受け取り、繰り返します。各ハンドオフごとに、ポリシー重視の部分が少なくなります。
ここでは、流れを実際に動作させるには、有用な製品ウォークスルーがあります。
Firebaseでは十分ではありません。
Firebaseは、Play Consoleの完全な置き換えではありません。 より速いプレリリースレーンであり、Androidのリリースシステム全体ではありません。
ここで、必要なのは以下の機能です。
- ストアネイティブベータの可視性: ベータを、生産リリースパスの同じ場所で管理したい。
- パブリックエンロールメント: 招待テストからより広範なパブリック アクセスに移行しています。
- 運用の連続性: リリース マネージャー、サポート、製品全体がテストからプロダクションまでの 1 つのカノニカル パスを求めています。
質問は「Play Console または Firebase？」ではありません。最も成熟したチームはどちらを使用するかは異なる時期に異なるツールを使用しますが。
実用的には、分割は簡単です。ビルド速度が高く、対象者が制御されている場合に Firebase を使用し、リリース管理が速度よりも重要な場合に Play トラックを使用します。
Android の Beta Distribution オプションの比較
Android の TestFlight アプリを探すのをやめると、決定は簡単になります。選択するのは、同等のツールの間ではなく、 管理されたリリース トラック と 高速ビルド配布.
iOS 開発者にとって、Apple の制約は有用な基準です。TestFlight は最大で 100 人の内部テスターをサポートします と 10,000の外部テスター アプリごとに、外部ベータレビューは約 48時間、それぞれのビルドは90日で有効期限切れ 、このTestFlightの開発者向け概要 。 Androidは、トラックベースのワークフローであるため、直接アプリベースの制約を反映していません。Androidのベータテスト方法の比較
機能
| Google Playのトラック | __CAPGO_KEEP_0__ | Firebase App Distribution |
|---|---|---|
| __CAPGO_KEEP_0__ | 公式Androidベータ版およびプレプロダクションリリース管理 | テスターと迅速にビルドを共有 |
| 最も適切なオプション | テストから正式なリリースまでの明確なパスを求めるチーム | 正式なロールアウト前に迅速な反復が必要なチーム |
| テスターへのアクセスモデル | 内部、閉鎖、またはオープンテストトラックを通じて管理 | テスターへの直接配布、招待または共有アクセスフロー |
| 正式なリリースまでのパス | Playリリースプロセスにネイティブ | ストアリリースパイプラインとは別 |
| 運用上の負担 | より構造化された | 日常のビルドハンドオフのために軽量 |
| パブリックベータの適さ | 強い | ストアベースの登録と比較して制限された |
| CI/CDの有用性 | リリースプロモーションに特に良い | 頻繁な候補配信に非常に良い |
| 最適な使用例 | 統制とプロモーション管理が必要なベータプログラム | 迅速なQA、ステークホルダーレビュー、内部検証 |
リリースツールのより広いスタックを評価している場合、この アプリ更新管理ツール ベータ配信がより広いリリースツールチェーンにどのように組み込まれているかについての役立つコンテキストを追加します。
複雑にしないで選択する方法
ここがポイントです。
選択 Google Play Tracks リリース管理が主な懸念事項であれば、このオプションを選択してください。
ユーザー分割、生産環境への進展、オフィシャルアプリストアのワークフロー内にベータ活動を維持したいということです。 選択 Firebase App Distribution
__CAPGO_KEEP_0__の場合、チームが異なるプレリリースフェーズを持っている場合、両方を使用します。多くの場合、そうなります。
- __CAPGO_KEEP_0__のサイクル: __CAPGO_KEEP_0__のためのFirebase
- 安定化: __CAPGO_KEEP_0__のClosed Playトラック:外部ベータ検証用
- __CAPGO_KEEP_0__の前リリースまたは広範なベータ: __CAPGO_KEEP_0__のOpen Playトラック
- リリース: __CAPGO_KEEP_0__のPlayを通じたプロダクションロールアウト
Androidのメンタルモデルとして、通常、TestFlightを最もきれいに置き換えます。
伝統的なベータ配布の制限事項
ベータテストは役立ちます。ただし、プロダクションの現実から救うものではありません。
モバイルリリース作業の不快な部分は、優れたQA、慎重に閉鎖されたベータ、段階的なリリースの後にまだバグがスリップする可能性があることです。特定の顧客構成でしか現れない場合もあります。生産データ、ライブバックエンドの動作、テスターが再現しない使用パターンが必要になる場合もあります。
ベータテストはリスクを軽減しますが、リスクを完全に排除することはありません
ベータ配布は リリース前 の問題を解決します。チームに安全な場所を与え、バイナリ、パーミッション、フロー、互換性を検証することができます。
リリース後 の問題を解決しません。アプリがライブになった後、通常の修正パスは、新しいバイナリを作成し、ストアプロセスを通じて提出し、ユーザーが更新を受信またはインストールするのを待つことです。 そのラグは、チームが脆弱な状態になるのです。
実際にリリース後に痛みを感じるのは
リリース後の問題はほとんどの場合、単なるバグではありません。運用上の問題になります。
__CAPGO_KEEP_0__
- サポートは最初に感じます: ユーザーはエンジニアリングが修正を配布する前に問題に当たっています。
- 製品はコントロールを失います: メッセージング、UIの調整、そして小さな論理的な修正はバイナリーリリースのスピードに結びついています。
- リリースマネージャーは選択肢を失います: Even minor non-native changes still wait behind the same store delivery path.
あなたがCapacitorまたはハイブリッドアプリケーションを使用している場合、そのギャップは特に悩ましいです。なぜなら、緊急の修正はウェブアセットではなく、ネイティブのcodeに住んでいないからです。このガイドは ベータワークフローにおけるポリシー準拠のOTAアップデートのガイド は便利です。なぜなら、ベータツールがうまく処理しない部分に取り組んでいるからです。すでにユーザーの手の中にあるバイナリがすでに配布されている状況で、制御されたアップデートを実行することです。
真実は簡単です。ベータテストは不良リリースの可能性を下げます。ただし、生産がまだ壊れている場合、回復の高速ルートを提供しません。
Capgo Live Updatesのベースライン
ベータテストの限界を超えて__CAPGO_KEEP_0__ Live Updatesを使用することの利点 Capacitor アプリ生産復旧のギャップを対処するために、別のツールカテゴリがあります:ウェブアセットのライブアップデート。 それがPlayトラックスやFirebaseの置き換えではありません。別の問題を解決するものです。
ライブアップデートが解決すること
Androidアプリがウェブ層を配信している場合、生産問題を修正するためにフルバイナリーリリースが必要ではない場合があります。 JavaScript、HTML、CSS、コピー、設定、またはバンドルされたアセットその場合、ライブアップデートシステムは回復パスを短縮できます。
オプションの1つは Capgoでアプリストア安全のOTAアップデート、ターゲットチャンネルに署名されたウェブバンドルを公開し、Capacitorアプリの起動時にはアップデートを適用します。
チームは、フルアプリストアサイクルを経由しなくても、非バイナリーフィックスをプッシュできます。
- 有用な例としては、次のものがあります: __CAPGO_KEEP_0__は機能フラグの変更後に破損したレイアウトです。
- __CAPGO_KEEP_0__と設定の修正: __CAPGO_KEEP_0__、悪いデフォルト、または環境に依存する問題です。
- __CAPGO_KEEP_0__用のパッチ: __CAPGO_KEEP_0__用のワークアラウンドです。
__CAPGO_KEEP_0__はAndroidワークフローのどこに当てはまりますか
__CAPGO_KEEP_0__の考え方は正しいです __CAPGO_KEEP_0__層.
Google Play Consoleを使用してAndroidバイナリをテストまたは配信するときは、Firebaseを使用して迅速なプレリリースの反復を必要とするときは、既に生産環境でバイナリが存在し、修正はWeb層に存在するときは、ライブアップデートパスを使用します。
__CAPGO_KEEP_0__はリスクのコントロールを提供します:
- __CAPGO_KEEP_0__ __CAPGO_KEEP_0__を通じてベータテスト
- Store-managed launch discipline Playを通じて
- Post-release recovery webアセットの問題に対して、別のバイナリサイクルを待つことなく対処します。
アプリが大きなweb層を持っている場合、ベータテストを全体のリリース戦略として扱うと、最も費用の高い事故が発生する場所にギャップが生じます。
このトレードオフも重要です。ライブアップデートはネイティブcodeのリリースを置き換えるものではありません。Kotlinのバグ、パーミッションマニフェスト、ネイティブSDK、またはバイナリパッケージングの場合でも、標準のストアパスが必要です。ただし、ネイティブシェルの上にあるクラスの問題に対しては、このオプションはチームに速い反応オプションを提供します。
モダンなAndroidリリースワークフローを作成する
実用的AndroidワークフローはiOSをコピーするのではなく、Androidツールをその用途に適したものとして使用します。
使用 Firebase App Distribution エンジニアとQAが高速なビルドのターンオーバーを必要とする場合に使用します。フィードバックループを短くし、機能がまだ動き、リリース候補が不安定なときに使用します。
安定した候補を移動する Google Play のクローズドテスト 外部の検証に、より構造化されたものが必要な場合に使用します。通常、利害関係者、パイロットカスタマー、そして本格的なベータユーザーにとって、この場所が適しています。アプリが安定して、より広範な露出から利益を得られるようになるまで、オープンテストに拡大するのはやめましょう。
「 Capacitor アプリ」の場合、ライブアップデートのパスを用意しておきましょう。Nativeの変更が必要ない修正のために、リリース後の修正に備えておきましょう。そうすると、「テストがうまくいった」と「生産環境で驚かれた」間のギャップが閉じるのです。
簡単な「どの時点で何を使用するか」というルールがうまく機能します。
- Firebase 内部の迅速な反復
- Playの内部またはクローズドトラック Androidのマネージドベータテスト
- Playのオープンテスト より広範なリリース前の露出
- リアルタイム更新 リリース後非二次元ホットフィックス用
テストフライトの現代的な答えです。Android上のApple TestFlightアプリはありませんが、1つのツールがすべての作業を実行することを期待しない限り、成熟したリリーススタックがあります。
チームがCapacitorアプリを配信し、リリース後ウェブ修正を迅速に提供する必要がある場合、 Capgo Play ConsoleとFirebaseと並行して評価する価値があります。Androidベータテストを置き換えるものではありません。アプリがすでに公開されている場合に、提供する部分をカバーします。
