Pisahkan lingkungan pengembang dan pengembang Firebase

Saya mempertimbangkan untuk menggunakan Firebase sebagai MBaaS, namun saya tidak dapat menemukan solusi yang dapat diandalkan untuk masalah berikut:

Saya ingin menyiapkan dua lingkungan Firebase yang terpisah, satu untuk pengembangan dan satu untuk produksi, tetapi saya tidak ingin melakukan salinan fitur secara manual (mis. Pengaturan konfigurasi jarak jauh, aturan pemberitahuan, dll.) Antara lingkungan pengembangan dan produksi .

Apakah ada alat atau metode yang bisa saya andalkan? Menyiapkan konfigurasi jauh atau aturan notifikasi dari awal dapat menjadi tugas yang menakutkan dan terlalu berisiko.

Ada saran? Apakah ada pendekatan yang lebih baik daripada memiliki dua lingkungan yang terpisah?

Sebelum Anda mengirim jawaban lain untuk pertanyaan yang menjelaskan cara mengatur akun Firebase yang terpisah: ini bukan pertanyaannya, bacalah lagi. Pertanyaannya adalah: bagaimana cara TRANSFER mengubah antara akun dev dan prod yang terpisah atau solusi yang lebih baik daripada menyalin secara manual di antara mereka.

Seperti yang semua orang tunjukkan - Anda membutuhkan lebih dari satu proyek / database.

Tetapi untuk menjawab pertanyaan Anda mengenai perlunya dapat menyalin pengaturan / data dll dari pengembangan hingga produksi. Saya memiliki kebutuhan yang sama persis. Beberapa bulan dalam pengembangan dan pengujian, saya tidak ingin menyalin data secara manual.

Hasil saya adalah mem-backup data ke ember penyimpanan, dan kemudian mengembalikannya dari sana ke database lain. Ini cara yang cukup kasar untuk melakukannya - dan saya melakukan backup / restore seluruh database - tetapi Anda mungkin dapat melihat ke arah itu untuk cara yang lebih terkontrol. Saya belum menggunakannya - ini sangat baru - tetapi ini mungkin solusi: Modul NPM firestore-ekspor-impor

Sunting : Firestore backup / ekspor / impor info di sini Cloud Firestore Mengekspor dan Mengimpor Data

Jika Anda menggunakan Firebase RTDB, dan bukan Firestore - dokumentasi ini mungkin membantu: Firebase Backup Otomatis

Anda perlu mengatur izin dengan benar untuk memungkinkan akses database produksi Anda ke ember penyimpanan yang sama dengan pengembangan Anda. Semoga berhasil.

Jika Anda menggunakan firebase-tools ada perintah firebase useyang memungkinkan Anda mengatur proyek yang Anda gunakanfirebase deploy

firebase use --addakan memunculkan daftar proyek Anda, pilih satu dan itu akan meminta Anda untuk alias. Dari sana Anda dapat firebase use aliasdan firebase deployakan mendorong ke proyek itu.

Dalam penggunaan pribadi saya, saya memiliki aplikasi dan aplikasi saya sebagai proyek di konsol Firebase.

Saat ini saya tidak menggunakan Firebase, tetapi mempertimbangkannya seperti diri Anda sendiri. Sepertinya cara yang harus dilakukan adalah membuat proyek yang sepenuhnya terpisah di konsol. Ada posting blog yang merekomendasikan hal ini di situs Firebase lama, sepertinya sudah dihapus sekarang. https://web.archive.org/web/20160310115701/https://www.firebase.com/blog/2015-10-29-managing-development-environmentments.html

Juga diskusi ini merekomendasikan hal yang sama: https://groups.google.com/forum/#!msg/firebase-talk/L7ajIJoHPcA/7dsNUTDlyRYJ

Cara saya melakukannya:

1. Saya punya 2 proyek di firebase-satu untuk DEV lainnya untuk PROD
2. Secara lokal aplikasi saya juga memiliki 2 cabang - satu bernama DEV, yang lainnya bernama PROD
3. Di cabang DEV saya, saya selalu memiliki file JSON dari proyek firebase DEV & juga untuk PROD

Dengan cara ini saya tidak diharuskan untuk memelihara JSON saya.

Blogpost ini menjelaskan pendekatan yang sangat sederhana dengan tipe debug dan rilis build.

Pendeknya:

• Buat Aplikasi baru di Firebase untuk setiap tipe build menggunakan akhiran id aplikasi yang berbeda.
• Konfigurasikan proyek Android Anda dengan file JSON terbaru.
• Menggunakan applicationIdSuffix, ubah Id Aplikasi untuk mencocokkan Aplikasi yang berbeda di Firebase tergantung pada tipe build.

=> lihat blogpost untuk deskripsi terperinci.

Jika Anda ingin menggunakan rasa yang berbeda, baca blogpost yang luas ini dari blog firebase resmi. Ini berisi banyak informasi berharga.

Semoga itu bisa membantu!

Anda perlu mengelola berbagai jenis bangunan

Ikuti ini

1. Pertama, buat proyek baru di Firebase console, beri nama id sebagai YOURAPPNAME-DEV

2. Klik tombol "Tambahkan aplikasi android" dan buat aplikasi baru. Beri nama com.yourapp.debug, misalnya. File google-services.json baru akan diunduh secara otomatis

3. Di bawah direktori src proyek Anda, buat direktori baru dengan nama "debug" dan salin file google-services.json baru di sini

4. Di build.gradle tingkat modul Anda, tambahkan ini

   debug {
           applicationIdSuffix ".debug"
       }
   

Sekarang ketika Anda membangun membangun debug google-services.json dari folder "debug" akan digunakan dan ketika Anda akan membangun dalam mode rilis google-services.json dari direktori root modul akan dipertimbangkan.

Untuk mengatasi ini untuk situasi saya, saya membuat tiga proyek Firebase, masing-masing dengan proyek Android yang sama (yaitu sama applicationIdtanpa menggunakan yang applicationIdSuffixdisarankan oleh orang lain). Ini menghasilkan tiga file google-services.json yang saya simpan di server Continuous Integration (CI) saya sebagai variabel lingkungan kustom . Untuk setiap tahap pembuatan (dev / staging / prod), saya menggunakan file google-services.json yang sesuai.

Untuk proyek Firebase yang terkait dengan dev, dalam proyek Android-nya, saya menambahkan sidik jari sertifikat SHA debug. Tetapi untuk staging dan prod, saya hanya perlu CI menandatangani APK.

Berikut ini adalah strip-down .gitlab-ci.ymlyang berfungsi untuk pengaturan ini:

# This is a Gitlab Continuous Integration (CI) Pipeline definition
# Environment variables:
#   - variables prefixed CI_ are Gitlab predefined environment variables (https://docs.gitlab.com/ee/ci/variables/predefined_variables.html)
#   - variables prefixed GNDR_CI are Gitlab custom environment variables (https://docs.gitlab.com/ee/ci/variables/#creating-a-custom-environment-variable)
#
# We have three Firebase projects (dev, staging, prod) where the same package name is used across all of them but the
# debug signing certificate is only provided for the dev one (later if there are other developers, they can have their
# own Firebase project that's equivalent to the dev one).  The staging and prod Firebase projects use real certificate
# signing so we don't need to enter a Debug signing certificate for them.  We don't check the google-services.json into
# the repository.  Instead it's provided at build time either on the developer's machine or by the Gitlab CI server
# which injects it via custom environment variables.  That way the google-services.json can reside in the default
# location, the projects's app directory.  The .gitlab-ci.yml is configured to copy the dev, staging, and prod equivalents
# of the google-servies.json file into that default location.
#
# References:
# https://firebase.googleblog.com/2016/08/organizing-your-firebase-enabled-android-app-builds.html
# /programming/57129588/how-to-setup-firebase-for-multi-stage-release

stages:
  - stg_build_dev
  - stg_build_staging
  - stg_build_prod

jb_build_dev:
  stage: stg_build_dev
  image: jangrewe/gitlab-ci-android
  cache:
    key: ${CI_PROJECT_ID}-android
    paths:
      - .gradle/
  script:
    - cp ${GNDR_CI_GOOGLE_SERVICES_JSON_DEV_FILE} app/google-services.json
    - ./gradlew :app:assembleDebug
  artifacts:
    paths:
      - app/build/outputs/apk/

jb_build_staging:
  stage: stg_build_staging
  image: jangrewe/gitlab-ci-android
  cache:
    key: ${CI_PROJECT_ID}-android
    paths:
      - .gradle/
  dependencies: []
  script:
    - cp ${GNDR_CI_GOOGLE_SERVICES_JSON_STAGING_FILE} app/google-services.json
    - ./gradlew :app:assembleDebug
  artifacts:
    paths:
      - app/build/outputs/apk/

jb_build_prod:
  stage: stg_build_prod
  image: jangrewe/gitlab-ci-android
  cache:
    key: ${CI_PROJECT_ID}-android
    paths:
      - .gradle/
  dependencies: []
  script:
    - cp ${GNDR_CI_GOOGLE_SERVICES_JSON_PROD_FILE} app/google-services.json

    # GNDR_CI_KEYSTORE_FILE_BASE64_ENCODED created on Mac via:
    # base64 --input ~/Desktop/gendr.keystore --output ~/Desktop/keystore_base64_encoded.txt
    # Then the contents of keystore_base64_encoded.txt were copied and pasted as a Gitlab custom environment variable
    # For more info see http://android.jlelse.eu/android-gitlab-ci-cd-sign-deploy-3ad66a8f24bf
    - cat ${GNDR_CI_KEYSTORE_FILE_BASE64_ENCODED} | base64 --decode > gendr.keystore

    - ./gradlew :app:assembleRelease
      -Pandroid.injected.signing.store.file=$(pwd)/gendr.keystore
      -Pandroid.injected.signing.store.password=${GNDR_CI_KEYSTORE_PASSWORD}
      -Pandroid.injected.signing.key.alias=${GNDR_CI_KEY_ALIAS}
      -Pandroid.injected.signing.key.password=${GNDR_CI_KEY_PASSWORD}
  artifacts:
    paths:
      - app/build/outputs/apk/

Saya senang dengan solusi ini karena tidak bergantung pada trik build.gradle yang saya yakini terlalu buram dan karenanya sulit dipertahankan. Sebagai contoh, ketika saya mencoba menggunakan pendekatan applicationIdSuffixdan berbeda buildTypesaya menemukan bahwa saya tidak bisa mendapatkan tes instrumented untuk menjalankan atau bahkan kompilasi ketika saya mencoba untuk beralih menggunakan tipe build testBuildType. Android tampaknya memberikan properti khusus debug buildTypeyang saya tidak bisa menginspeksi untuk memahaminya.

Sebenarnya, skrip CI cukup transparan dan mudah dirawat, menurut pengalaman saya. Memang, pendekatan yang saya jelaskan berhasil: Ketika saya menjalankan masing-masing APK yang dihasilkan oleh CI pada emulator, langkah "Jalankan aplikasi Anda untuk memverifikasi pemasangan" konsol Firebase berjalan dari

Memeriksa apakah aplikasi telah berkomunikasi dengan server kami. Anda mungkin perlu menghapus dan menginstal ulang aplikasi Anda.

untuk:

Selamat, Anda berhasil menambahkan Firebase ke aplikasi Anda!

untuk ketiga aplikasi saat saya memulai satu per satu di emulator.

Firebase memiliki halaman tentang ini yang membahas cara mengaturnya untuk dev dan prod

https://firebase.google.com/docs/functions/config-env

Mengatur konfigurasi lingkungan untuk proyek Anda Untuk menyimpan data lingkungan, Anda dapat menggunakan fungsi firebase: config: set perintah di Firebase CLI. Setiap kunci dapat di-namespace menggunakan periode untuk mengelompokkan konfigurasi terkait bersama-sama. Perlu diingat bahwa hanya karakter huruf kecil yang diterima dalam tombol; karakter huruf besar tidak diperbolehkan.

Misalnya, untuk menyimpan ID Klien dan kunci API untuk "Some Service", Anda dapat menjalankan:

firebase functions:config:set someservice.key="THE API KEY" someservice.id="THE CLIENT ID"

Ambil konfigurasi lingkungan saat ini Untuk memeriksa apa yang saat ini disimpan dalam konfigurasi lingkungan untuk proyek Anda, Anda dapat menggunakan fungsi firebase: config: get. Ini akan menampilkan JSON seperti ini:

{
  "someservice": {
    "key":"THE API KEY",
    "id":"THE CLIENT ID"
  }
}

Saya memperbarui jawaban ini berdasarkan informasi yang baru saja saya temukan.

Langkah 1

Di firebase.google.com, buat beberapa lingkungan Anda (mis; dev, staging, prod)

mysite-dev

pementasan mysite

mysite-prod

Langkah 2

Sebuah. Pindah ke langsung yang Anda inginkan sebagai default Anda (mis; dev)

b. Larifirebase deploy

c. Setelah dikerahkan, jalankanfirebase use --add

d. Sebuah opsi akan muncul untuk memilih dari berbagai proyek yang Anda miliki saat ini.

Gulir ke proyek yang ingin Anda tambahkan: mysite-staging , dan pilih.

e. Anda kemudian akan diminta nama alias untuk proyek itu. Masukkan pementasan .

Jalankan item ae lagi untuk prod dan dev, sehingga setiap lingkungan akan memiliki alias

Ketahui di lingkungan mana Anda berada

Lari firebase use default (mysite-dev)

* dev (mysite-dev)

staging (mysite-staging)

prod (mysite-dev)

(salah satu lingkungan akan memiliki tanda bintang di sebelah kiri itu. Itu yang sedang Anda masuki. Itu juga akan disorot dengan warna biru)

Beralih di antara lingkungan

Jalankan firebase use stagingatau firebase use produntuk bergerak di antara mereka.

Setelah Anda berada di lingkungan yang Anda inginkan, jalankan firebase deploydan proyek Anda akan disebarkan di sana.

Berikut beberapa tautan bermanfaat ...

Referensi CLI

Menyebarkan ke beberapa lingkungan

Semoga ini membantu.

Cara kita melakukannya adalah dengan membuat file kunci json yang berbeda untuk lingkungan yang berbeda. Kami telah menggunakan fitur akun layanan seperti yang direkomendasikan oleh google dan memiliki satu file pengembangan dan lainnya untuk produksi

Buat proyek Tow dengan Dev dan Lingkungan produksi di firebase Unduh file json dari thre

dan siapkan SDK sesuai: https://firebase.google.com/docs/android/setup Atau untuk Crashlytics: https://firebase.google.com/docs/crashlytics/get-started?platform=android

Pertama, letakkan masing-masing google_services.json untuk setiap buildType di lokasi berikut:

app/src/debug/google_services.json
app/src/test/google_services.json
app/google_services.json

Catatan: Root app / google_services.json File ini harus ada di sana sesuai dengan varian build, salin kode json di file root json

Sekarang, mari kita siapkan beberapa tugas tingkat di: build.gradle aplikasi Anda untuk mengotomatiskan memindahkan google_services.json yang sesuai ke app / google_services.json

salin ini di file app / Gradle

task switchToDebug(type: Copy) {
description = 'Switches to DEBUG google-services.json'
from "src/debug"
include "google-services.json"
into "."
}

task switchToRelease(type: Copy) {
description = 'Switches to RELEASE google-services.json'
from "src/release"
include "google-services.json"
into "."
}

Hebat - tetapi harus secara manual menjalankan tugas-tugas ini sebelum Anda membangun aplikasi Anda rumit. Kami ingin tugas penyalinan yang sesuai dijalankan di atas beberapa saat sebelumnya: assembleDebug atau: assembleRelease dijalankan. Mari kita lihat apa yang terjadi ketika: assembleRelease dijalankan: salin yang ini di file / gradlew

Zaks-MBP:my_awesome_application zak$ ./gradlew assembleRelease
Parallel execution is an incubating feature.
.... (other tasks)
:app:processReleaseGoogleServices
....
:app:assembleRelease

Perhatikan tugas: app: processReleaseGoogleServices. Tugas ini bertanggung jawab untuk memproses file root google_services.json. Kami ingin google_services.json yang benar diproses, jadi kami harus segera menjalankan tugas penyalinan kami. Tambahkan ini ke build.gradle Anda. Perhatikan penutup afterEvaluate.

salin ini di file app / Gradle

afterEvaluate {
processDebugGoogleServices.dependsOn switchToDebug
processReleaseGoogleServices.dependsOn switchToRelease
}

Sekarang, kapan saja: app: processReleaseGoogleServices dipanggil, aplikasi kami yang baru: switchToRelease akan dipanggil sebelumnya. Logika yang sama untuk buildType debug. Anda dapat menjalankan: app: assembleRelease dan versi rilis google_services.json akan secara otomatis disalin ke folder root modul aplikasi Anda.