Ayrı geliştirici ve ürün Firebase ortamı

Firebase'i MBaaS olarak kullanmayı düşünüyorum, ancak aşağıdaki soruna güvenilir bir çözüm bulamadım:

Biri geliştirme ve diğeri üretim için olmak üzere iki ayrı Firebase ortamı kurmak istiyorum, ancak geliştirme ve üretim ortamı arasında özelliklerin manuel kopyasını (örn. Uzaktan yapılandırma kurulumu, bildirim kuralları vb.) Yapmak istemiyorum. .

Güvenebileceğim herhangi bir araç veya yöntem var mı? Uzaktan yapılandırma veya bildirim kurallarını sıfırdan ayarlamak göz korkutucu olabilir ve çok riskli olabilir.

Baska öneri? İki ayrı ortama sahip olmaktan daha iyi bir yaklaşım var mı?

Ayrı Firebase hesaplarının nasıl kurulacağını açıklayan soruya başka bir cevap göndermeden önce: soru bu değildir, tekrar okuyun. Soru şudur: Değişik dev ve prod hesapları arasında değişikliklerin nasıl transfer edileceği veya aralarında manuel olarak kopyalamaktan daha iyi bir çözüm.

Herkesin işaret ettiği gibi, birden fazla projeye / veritabanına ihtiyacınız var.

Ancak ayarları / verileri vb. Geliştirmeden üretime kopyalayabilme ihtiyacı ile ilgili sorunuza cevap vermek için. Aynı ihtiyacı vardı. Geliştirme ve testte birkaç ay, verileri manuel olarak kopyalamak istemedim.

Sonucum, verileri bir depolama grubuna yedeklemek ve daha sonra diğer veritabanına geri yüklemekti. Bunu yapmanın oldukça kaba bir yoludur - ve bir veritabanı yedeklemesi / geri yüklemesi yaptım - ama daha kontrollü bir şekilde bu yöne bakabilirsiniz. Kullanmadım - çok yeni - ama bu bir çözüm olabilir: NPM Modülü firestore-export-import

Düzenleme : Firestore yedekleme / dışa aktarma / içe aktarma bilgileri burada Cloud Firestore Verileri Dışa Aktarma ve İçe Aktarma

Firestore değil Firebase RTDB kullanıyorsanız - bu belgeler yardımcı olabilir: Firebase Otomatik Yedeklemeler

Üretim veritabanınızın, gelişiminizle aynı depolama grubuna erişmesine izin vermek için izinleri doğru bir şekilde ayarlamanız gerekir. İyi şanslar.

Firebase-tools kullanıyorsanız, firebase usehangi projeyi kullandığınızı ayarlamanıza izin veren bir komut vardır.firebase deploy

firebase use --addprojelerinizin bir listesini getirecek, birini seçin ve sizden bir takma ad isteyecektir. Oradan olabilir firebase use aliasve firebase deploybu projeye itecektir.

Kişisel kullanımımda, Firebase konsolunda benim app ve my-app-dev projelerim var.

Şu anda Firebase kullanmıyorum, ama kendiniz gibi görüyorum. Görünüşe göre, konsol üzerinde tamamen ayrı bir proje oluşturmak. Eski Firebase sitesinde bunu öneren bir blog yazısı vardı, şimdi kaldırılmış görünüyor. https://web.archive.org/web/20160310115701/https://www.firebase.com/blog/2015-10-29-managing-development-environments.html

Aynı şeyi öneren bu tartışma: https://groups.google.com/forum/#!msg/firebase-talk/L7ajIJoHPcA/7dsNUTDlyRYJ

Yaptığım yol:

1. Firebase'de 2 tane projem vardı - biri PROD için DEV için
2. Yerel olarak benim uygulamam da 2 şube vardı - biri DEV adlı, diğeri PROD adlı
3. DEV şubemde her zaman DEV firebase projesinin JSON dosyasına sahibim ve benzer şekilde PROD için

Bu şekilde JSON'larımı korumak zorunda değilim.

Bu blog yazısı , hata ayıklama ve sürüm oluşturma türüyle çok basit bir yaklaşımı açıklar.

Kısaca:

• Farklı uygulama kimliği soneki kullanarak her derleme türü için Firebase'de yeni bir Uygulama oluşturun.
• Android projenizi en son JSON dosyasıyla yapılandırın.
• ApplicationIdSuffix'i kullanarak, Uygulama Türünü derleme türüne bağlı olarak Firebase'deki farklı Uygulamalarla eşleşecek şekilde değiştirin.

=> detaylı açıklama için blog yazısına bakınız.

Farklı yapı lezzetleri kullanmak istiyorsanız , resmi kapsamlı web sitesi blogundan bu kapsamlı blog yazısını okuyun . Birçok değerli bilgi içerir.

Umarım yardımcı olur!

Farklı yapı türlerini yönetmeniz gerekecek

Bunu takip et

1. İlk olarak, Firebase konsolunda yeni bir proje oluşturun, kimliği YOURAPPNAME-DEV olarak adlandırın

2. "Android uygulaması ekle" düğmesini tıklayın ve yeni bir uygulama oluşturun. Örneğin, com.yourapp.debug olarak adlandırın. Yeni google-services.json dosyası otomatik olarak indirilecek

3. Proje src dizininizin altında "debug" adıyla yeni bir dizin oluşturun ve yeni google-services.json dosyasını buraya kopyalayın

4. Modül düzeyinde build.gradle bunu ekleyin

   debug {
           applicationIdSuffix ".debug"
       }
   

Şimdi bir hata ayıklama oluşturduğunuzda "debug" klasöründen google-services.json oluşturulacak ve serbest bırakma modunda oluşturduğunuz zaman modül kök dizininden google-services.json dikkate alınacaktır.

Bunu durumum için çözmek için, her biri aynı Android projesine (yani başkaları tarafından önerilenleri applicationIdkullanmadan) sahip üç Firebase projesi oluşturdum applicationIdSuffix. Bu, Sürekli Entegrasyon (CI) sunucumda özel ortam değişkenleri olarak sakladığım üç google-services.json dosyasıyla sonuçlandı . Derlemenin her aşaması için (dev / staging / prod), ilgili google-services.json dosyasını kullandım.

Dev ile ilişkili Firebase projesi için Android projesinde hata ayıklama SHA sertifikası parmak izini ekledim. Ama evreleme ve eşya için APK'yı imzalamam yeterli.

İşte .gitlab-ci.ymlbu kurulum için çalışan bir soyulmuş :

# 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/

Bu çözümden memnunum çünkü çok opak ve bu nedenle bakımı zor olduğuna inandığım build.gradle hilelerine dayanmıyor. Örneğin, yaklaşımları kullanarak denediğimde applicationIdSuffixve farklı buildTypes kullanarak derleme türlerini değiştirmeye çalıştığımda çalıştırmak veya hatta derlemek için enstrümanlı testler alamadım testBuildType. Android debug buildType, anlayamadığım denetleyemediğim özel özellikler veriyor gibiydi .

Neredeyse, CI betikleri benim deneyimime göre oldukça şeffaf ve bakımı kolaydır. Aslında, tarif ettiğim yaklaşım işe yaradı: CI tarafından üretilen APK'ların her birini bir emülatörde çalıştırdığımda, Firebase konsolunun "Yüklemeyi doğrulamak için uygulamanızı çalıştırın" adımı

Uygulamanın sunucularımızla iletişim kurup kurmadığını kontrol etme. Uygulamanızı kaldırmanız ve yeniden yüklemeniz gerekebilir.

için:

Tebrikler, uygulamanıza Firebase'i başarıyla eklediniz!

her üç uygulama için bir emülatörde tek tek başlattığım için.

Firebase'in bu konuda geliştirici ve prod için nasıl ayarlanacağını gösteren bir sayfası var

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

Projeniz için ortam yapılandırmasını ayarlama Ortam verilerini depolamak için, Firebase CLI'daki firebase işlevlerini: config: set komutunu kullanabilirsiniz. Her tuş, ilgili yapılandırmayı birlikte gruplamak için nokta kullanarak ad boşluklarına sahip olabilir. Anahtarlarda yalnızca küçük harflerin kabul edildiğini unutmayın; büyük harfli karakterlere izin verilmez.

Örneğin, "Bazı Hizmetler" için İstemci Kimliği ve API anahtarını saklamak üzere şunları çalıştırabilirsiniz:

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

Geçerli ortam yapılandırmasını alma Projeniz için ortam yapılandırmasında o anda depolananları incelemek için, ateş tabanı işlevlerini kullanabilirsiniz: config: get. JSON böyle bir şey çıktı:

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

Bu cevabı bulduğum bilgilere dayanarak güncelliyoruz.

Aşama 1

Firebase.google.com'da birden çok ortamınızı oluşturun (ör. Geliştirme, hazırlama, prod)

mysite-dev

mysite-evreleme

mysite-prod

Adım 2

a. Varsayılanınız olmasını istediğiniz doğrudan taşı (yani; dev)

b. Çalıştırmakfirebase deploy

c. Dağıtıldıktan sonra çalıştırınfirebase use --add

d. Şu anda sahip olduğunuz farklı projeler arasından seçim yapabileceğiniz bir seçenek bulunacaktır.

Eklemek istediğiniz projeye ilerleyin: sitem-hazırlama ve onu seçin.

e. Daha sonra sizden bu proje için bir takma ad istenir. Evrelemeye girin .

Prod ve dev için öğeleri tekrar çalıştırın, böylece her ortamın bir takma adı olacak

Hangi ortamda olduğunuzu bilin

Çalıştırmak firebase use default (mysite-dev)

* dev (mysite-dev)

staging (mysite-staging)

prod (mysite-dev)

(ortamlardan birinin solunda bir yıldız işareti olacaktır. Şu anda bulunduğunuz alan budur. Ayrıca mavi ile vurgulanacaktır)

Ortamlar arasında geçiş yapma

Koşmak firebase use stagingveya firebase use prodaralarında hareket etmek.

İstediğiniz ortama girdikten sonra çalıştırın firebase deployve projeniz oraya dağılacaktır.

İşte birkaç faydalı link ...

CLI Başvurusu

Birden çok ortama dağıtım

Bu yardımcı olur umarım.

Bunu yapmanın yolu, farklı ortamlar için farklı json anahtar dosyaları oluşturmaktır. Google tarafından önerilen hizmet hesabı özelliğini kullandık ve üretim için bir geliştirme dosyamız ve diğeri var

Firebase üzerinde Dev ve üretim Ortamı ile Tow projesi oluşturun.

ve SDK'yı şu şekilde ayarlayın: https://firebase.google.com/docs/android/setup Veya Crashlytics için: https://firebase.google.com/docs/crashlytics/get-started?platform=android

İlk olarak, her buildType için ilgili google_services.json'u aşağıdaki konumlara yerleştirin:

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

Not: Kök uygulaması / google_services.json Bu dosya, yapı değişkenlerine göre kök json dosyasındaki json kodunu kopyalamalıdır

Şimdi, uygun google_services.json'u app / google_services.json'a taşımayı otomatikleştirmek için uygulamanızın build.gradle dosyasında bazı önemli görevleri toplayalım

bunu uygulamada / Gradle dosyasında kopyala

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 "."
}

Harika - ancak uygulamanızı oluşturmadan önce bu görevleri manuel olarak yürütmek zor bir iştir. Yukarıdaki uygun kopyalama görevinin bir süre önce çalıştırılmasını isteriz: assembleDebug veya: assembleRelease çalıştırılır. Bakalım ne olacak: assembleRelease çalıştırıldığında: bunu / gradlew dosyasına kopyalayın

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

: App: processReleaseGoogleServices görevine dikkat edin. Bu görev, kök google_services.json dosyasının işlenmesinden sorumludur. Doğru google_services.json'un işlenmesini istiyoruz, bu yüzden kopyalama görevimizi hemen çalıştırmalıyız. Bunu build.gradle dosyasına ekleyin. AfterEvaluate ekine dikkat edin.

bunu uygulamada / Gradle dosyasında kopyala

afterEvaluate {
processDebugGoogleServices.dependsOn switchToDebug
processReleaseGoogleServices.dependsOn switchToRelease
}

Şimdi, istediğiniz zaman: app: processReleaseGoogleServices çağrılır, yeni tanımladığımız: app: switchToRelease önceden çağrılır. BuildType hata ayıklaması için aynı mantık. Çalıştırabilirsiniz: app: assembleRelease ve google_services.json yayın sürümü otomatik olarak uygulama modülünüzün kök klasörüne kopyalanır.