[この記事は Doug Stevenson、デベロッパー アドボケートによる The Firebase Blog の記事 "Organizing your Firebase-enabled Android app builds " を元に翻訳・加筆したものです。詳しくは元記事をご覧ください。]
Doug Stevenson
デベロッパー アドボケート
「毎日の開発データとリリースデータを分けるには、どうすればよいでしょうか？」
実際 のアプリの利用データ（開発時の 人為的 な利用ではないもの）のみを反映させたいと誰もが思うでしょう。また、日々の開発でのクラッシュ データと、公開されているリリース版のクラッシュ データが混在していては不便です。何よりも、開発チームが拡大してアプリが複雑になると、お互いの作業が衝突しないように、各チームメンバーの作業環境を個々のサンドボックスに分割したいと考えるはずです。
Firebase コンソール のいくつかの設定と合わせて適用されます。
Firebase プロジェクト
[Firebase コンソール] のトップレベルで作成するプロジェクトです。作成したプロジェクトは、カード形式で表示されます。 Firebase アプリ
Firebase プロジェクト内に作成するアプリです。Firebase プロジェクトには、いくつでも Android アプリや iOS アプリを含めることができます。プロジェクトに含まれているアプリはホーム画面に表示され、同じ設定を共有します。また、異なる設定も持っています（この点は後ほど詳しく説明します）。 Android Gradle ビルドタイプ
Android Gradle プラグインはビルド時にアプリの設定を行い、その際にビルドタイプが定義されます。ビルドタイプには、デフォルトで「debug」と「release」の 2 種類があります。この設定は buildTypes ブロックで行われており、必要に応じてビルドタイプを追加することもできます。debug タイプは日々のデプロイ用、release タイプはユーザーへの配布用の設定です。 Android Gradle ビルド フレーバー
ビルド時に Android アプリを設定する際に、オプションで「ビルド フレーバー」を割り当てることができます。これはビルドタイプとほぼ同じですが、ビルド フレーバーを使うと必要に応じてさらに細かい設定を行うことができます。たとえば、ほとんどの機能が同じで、アプリケーション ID や有効にする機能のみが異なる「無償」版と「有償」版の両方のアプリをビルドすることができます。 Android Gradle ビルド バリアント
ビルド バリアント は、ビルドタイプとビルド フレーバーの固有の組み合わせです。アプリのビルド設定では、タイプとフレーバーのそれぞれの組み合わせについて、必ずバリアントが 1 つだけ存在します。たとえば、debug と release というタイプを設定しており、「free」と「paid」というフレーバーを設定している場合、Android Gradle プラグインは「debug/free」、「debug/paid」、「release/free」、「release/paid」という組み合わせのバリアントを生成します。コードからビルドした APK は、必ず 1 つだけバリアントを持っています。Android アプリケーション ID
アプリを一意に識別する文字列の識別子です。Play ストアで公開する際、他のアプリと重複しない一意の値になっている必要があります。通常は、「com.company.project」のように Java パッケージ名形式のフォーマットを使用します。 Firebase 対応のアプリを効果的に設定する際に重要になる考え方があります。それは、個別のデータ コレクションが必要になるアプリのビルド バリアントごとに固有のアプリケーション ID を割り当てることです。 それには、最初にアプリの build.gradle を設定し、次に Firebase コンソールでミラーの設定を行います。しかし、アプリに最適な設定を決めるためには、プロジェクトとアプリの間で Firebase の各機能がどのように動作しているかについてもう少し知っておく必要があります。
Firebase 機能ごとのデータスコープ
データを共有 するものもあります。これらの機能のデータの「スコープ」は、Firebase プロジェクト全体であると言え、次の機能が該当します。
独立してデータ を持つものもあります。これらの機能のスコープは、Firebase プロジェクトの個々のアプリであると言え、次の機能が該当します。
アプリ セレクターが表示されている Analytics ダッシュボード
Remote Config は、プロジェクト内のアプリ間で異なる値を設定することができますが、デフォルトではすべてのアプリに同じ値が設定されます。
Notifications は、コンソールで選択したプロジェクト内の 1 つまたは複数のアプリを対象にできます。
Dynamic Links は、1 つの Android および / または 1 つの iOS アプリが対象になります。
どちらを対象にするかは、現在のプラットフォームに基づいてリンク自身が判断します。
Firebase Test Lab for Android は特殊なケースです。この機能には課金が有効になったプロジェクトが必要ですが、1 つのプロジェクトという制約はなく、任意の APK を対象にすることができます。そのため、無償プランで Firebase の開発を行いつつ有償プランの Test Lab で APK をテストしたい場合は、Test Lab 専用のまったく新しいプロジェクトを作成し、課金を有効にすることをお勧めします。Firebase 統合の有無に関わらず、このプロジェクトでどのようなアプリでもテストできます。
小規模チームとシンプルなアプリ
defaultConfig {
applicationId "com.company.project"
// etc...
}
buildTypes {
debug {
applicationIdSuffix ".debug"
}
release {
// etc...
}
}
1 つのプロジェクト内にあり、アプリ ID が異なるデバッグ用とリリース用の 2 つのアプリ
両方 のアプリを作成できたら、コンソールから google-services.json ファイルをダウンロードしてアプリに配置します。このファイルの中を見てみると、両方のアプリが記述されていることがわかるでしょう。Google サービス プラグインは、各バリアントのビルドの際にその設定が使われたかを検出します。 "client_info": {
"mobilesdk_app_id": "...",
"android_client_info": {
"package_name": "com.company.project.debug "
}
},
"client_info": {
"mobilesdk_app_id": "...",
"android_client_info": {
"package_name": "com.company.project "
}
google-services.json は、プロジェクト内のすべての Android アプリを含む
両方の アプリの帯域幅とストレージに対して行われます。そのため、開発中に大量のデータを取得すると、課金額が増加する可能性があります。課金額に驚いてしまうことがないように、[課金プラン] をよく理解しておいてください。
大規模チームと安全な開発
すべて のアカウントの すべて のプロジェクトの すべて のアプリで一意でなければなりません。そのため、チームのメンバーがデバッグキーを共有している場合、この設定は動作しません。
Firebase コンソールはパッケージ名と SHA-1 の組み合わせの重複を許可しない
いけません 。これは、チームメンバー間での競合を避けるためです。
開発、QA、ステージング、本番の各環境の分離
productFlavors {
dev {
}
qa {
}
prod {
}
}
app/
src/
main/
dev/
google-services.json (for dev only)
qa/
google-services.json (for qa only)
prod/
google-services.json (for prod only)
ご質問がある場合
firebase-talk Google Group から質問をお寄せください。緊急のサポートが必要な件については、Firebase Support サイトから問題をお送りください。また、私の Twitter アカウント CodingDoug もぜひフォローしてください。
Yoshifumi Yamaguchi - Developer Relations Team