Separate Entwickler- und Produkt-Firebase-Umgebung

Ich denke darüber nach, Firebase als MBaaS zu verwenden, konnte jedoch keine zuverlässige Lösung für das folgende Problem finden:

Ich möchte zwei separate Firebase-Umgebungen einrichten, eine für die Entwicklung und eine für die Produktion, aber ich möchte keine manuelle Kopie von Funktionen (z. B. Remote-Konfigurations-Setup, Benachrichtigungsregeln usw.) zwischen der Entwicklungs- und Produktionsumgebung erstellen .

Gibt es ein Werkzeug oder eine Methode, auf die ich mich verlassen kann? Das Einrichten von Remote-Konfigurations- oder Benachrichtigungsregeln von Grund auf kann eine entmutigende Aufgabe sein und zu riskant.

Irgendwelche Vorschläge? Gibt es einen besseren Ansatz als zwei separate Umgebungen?

Bevor Sie eine weitere Antwort auf die Frage veröffentlichen, in der erläutert wird, wie separate Firebase-Konten eingerichtet werden: Dies ist nicht die Frage. Lesen Sie sie erneut. Die Frage ist: Wie werden Änderungen zwischen separaten Entwicklungs- und Produktkonten übertragen oder eine bessere Lösung als das manuelle Kopieren zwischen diesen Konten?

Wie jeder betont hat, benötigen Sie mehr als ein Projekt / eine Datenbank.

Um Ihre Frage zu beantworten, ob Einstellungen / Daten usw. von der Entwicklung in die Produktion kopiert werden müssen. Ich hatte genau das gleiche Bedürfnis. Einige Monate in Entwicklung und Test wollte ich die Daten nicht manuell kopieren.

Mein Ergebnis war, die Daten in einem Speicherbereich zu sichern und von dort aus in der anderen Datenbank wiederherzustellen. Es ist ein ziemlich grober Weg, dies zu tun - und ich habe eine ganze Datenbank gesichert / wiederhergestellt -, aber Sie können möglicherweise in diese Richtung nach einem kontrollierten Weg suchen. Ich habe es nicht benutzt - es ist sehr neu - aber dies könnte eine Lösung sein: NPM-Modul Firestore-Export-Import

Bearbeiten : Firestore Backup / Export / Import Informationen hier Cloud Firestore Exportieren und Importieren von Daten

Wenn Sie Firebase RTDB und nicht Firestore verwenden, kann diese Dokumentation hilfreich sein: Firebase Automated Backups

Sie müssen die Berechtigungen korrekt festlegen, damit Ihre Produktionsdatenbank auf denselben Speicherbereich wie Ihre Entwicklung zugreifen kann. Viel Glück.

Wenn Sie Firebase-Tools verwenden, gibt es einen Befehl, mit firebase usedem Sie festlegen können, für welches Projekt Sie verwendenfirebase deploy

firebase use --addEs wird eine Liste Ihrer Projekte angezeigt. Wählen Sie eines aus und Sie werden nach einem Alias ​​gefragt. Von dort aus können firebase use aliasund firebase deploywerden Sie zu diesem Projekt pushen.

In meinem persönlichen Gebrauch habe ich meine App und meinen App-Entwickler als Projekte in der Firebase-Konsole.

Ich benutze derzeit keine Firebase, aber ich betrachte es als Sie. Es sieht so aus, als ob Sie ein völlig separates Projekt auf der Konsole erstellen müssen. Es gab einen Blogpost, der dies auf der alten Firebase-Site empfahl, der jedoch jetzt entfernt werden soll. https://web.archive.org/web/20160310115701/https://www.firebase.com/blog/2015-10-29-managing-development-environments.html

Auch diese Diskussion empfiehlt dasselbe: https://groups.google.com/forum/#!msg/firebase-talk/L7ajIJoHPcA/7dsNUTDlyRYJ

So wie ich es gemacht habe:

1. Ich hatte 2 Projekte auf Firebase - eines für DEV und eines für PROD
2. Vor Ort hatte meine App auch zwei Filialen - eine mit dem Namen DEV, die andere mit dem Namen PROD
3. In meinem DEV-Zweig habe ich immer eine JSON-Datei des DEV-Firebase-Projekts und ebenfalls für PROD

Auf diese Weise muss ich meine JSONs nicht warten.

Dieser Blogpost beschreibt einen sehr einfachen Ansatz mit einem Debug- und Release-Build-Typ.

In einer Nussschale:

• Erstellen Sie für jeden Build-Typ eine neue App in Firebase mit einem anderen Anwendungs-ID-Suffix.
• Konfigurieren Sie Ihr Android-Projekt mit der neuesten JSON-Datei.
• Ändern Sie mithilfe von applicationIdSuffix die Anwendungs-ID so, dass sie je nach Build-Typ den verschiedenen Apps in Firebase entspricht.

=> Eine ausführliche Beschreibung finden Sie im Blogpost.

Wenn Sie verschiedene Build-Varianten verwenden möchten, lesen Sie diesen umfangreichen Blogpost aus dem offiziellen Firebase-Blog. Es enthält viele wertvolle Informationen.

Hoffentlich hilft das!

Sie müssen verschiedene Build-Typen verwalten

Folge dies

1. Erstellen Sie zunächst ein neues Projekt in der Firebase-Konsole und nennen Sie die ID YOURAPPNAME-DEV

2. Klicken Sie auf "Android App hinzufügen" und erstellen Sie eine neue App. Nennen Sie es zum Beispiel com.yourapp.debug. Die neue Datei google-services.json wird automatisch heruntergeladen

3. Erstellen Sie unter Ihrem Projekt-src-Verzeichnis ein neues Verzeichnis mit dem Namen "debug" und kopieren Sie hier die neue Datei google-services.json

4. Fügen Sie dies in Ihrer Modulebene build.gradle hinzu

   debug {
           applicationIdSuffix ".debug"
       }
   

Wenn Sie jetzt ein Debug-Build erstellen, wird google-services.json aus dem Ordner "debug" verwendet, und wenn Sie im Release-Modus erstellen, wird google-services.json aus dem Modulstammverzeichnis berücksichtigt.

Um dies für meine Situation zu lösen, habe ich drei Firebase-Projekte mit jeweils demselben Android-Projekt erstellt (dh applicationIdohne die applicationIdSuffixvon anderen vorgeschlagenen). Dies führte zu drei google-services.json-Dateien, die ich als benutzerdefinierte Umgebungsvariablen auf meinem CI-Server (Continuous Integration) gespeichert habe . Für jede Phase des Builds (dev / staging / prod) habe ich die entsprechende Datei google-services.json verwendet.

Für das mit dev verknüpfte Firebase-Projekt habe ich in seinem Android-Projekt den Fingerabdruck des Debug-SHA-Zertifikats hinzugefügt. Aber für Inszenierung und Prod habe ich nur CI die APK unterschreiben lassen.

Hier ist eine abgespeckte Version .gitlab-ci.yml, die für dieses Setup funktioniert hat:

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

Ich bin mit dieser Lösung zufrieden, da sie nicht auf build.gradle-Tricks beruht, die meiner Meinung nach zu undurchsichtig und daher schwer zu warten sind. Als ich zum Beispiel die Ansätze mit applicationIdSuffixund mit verschiedenen buildTypes ausprobierte, stellte ich fest, dass ich keine instrumentierten Tests ausführen oder sogar kompilieren konnte, als ich versuchte, Build-Typen mit zu wechseln testBuildType. Android schien den Eigenschaften besondere Eigenschaften zu verleihen, debug buildTypedie ich nicht überprüfen konnte, um sie zu verstehen.

Nach meiner Erfahrung sind CI-Skripte jedoch ziemlich transparent und leicht zu warten. In der Tat hat der von mir beschriebene Ansatz funktioniert: Als ich alle von CI generierten APKs auf einem Emulator ausgeführt habe, wurde der Schritt "Führen Sie Ihre App aus, um die Installation zu überprüfen" der Firebase-Konsole ausgeführt

Überprüfen Sie, ob die App mit unseren Servern kommuniziert hat. Möglicherweise müssen Sie Ihre App deinstallieren und neu installieren.

zu:

Herzlichen Glückwunsch, Sie haben Firebase erfolgreich zu Ihrer App hinzugefügt!

für alle drei Apps, wie ich sie einzeln in einem Emulator gestartet habe.

Firebase hat eine Seite dazu, auf der beschrieben wird, wie man es für Entwickler und Produkte einrichtet

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

Festlegen der Umgebungskonfiguration für Ihr Projekt Zum Speichern von Umgebungsdaten können Sie die folgenden Firebase-Funktionen verwenden: config: set-Befehl in der Firebase-CLI. Jeder Schlüssel kann mithilfe von Punkten mit einem Namespace versehen werden, um die zugehörige Konfiguration zu gruppieren. Beachten Sie, dass in Schlüsseln nur Kleinbuchstaben akzeptiert werden. Großbuchstaben sind nicht zulässig.

Um beispielsweise die Client-ID und den API-Schlüssel für "Some Service" zu speichern, können Sie Folgendes ausführen:

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

Aktuelle Umgebungskonfiguration abrufen Um zu überprüfen, was derzeit in der Umgebungskonfiguration für Ihr Projekt gespeichert ist, können Sie die Firebase-Funktionen verwenden: config: get. Es wird JSON ungefähr so ​​ausgeben:

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

Ich aktualisiere diese Antwort basierend auf Informationen, die ich gerade gefunden habe.

Schritt 1

Erstellen Sie in firebase.google.com mehrere Umgebungen (z. B. dev, staging, prod).

mysite-dev

Mysite-Inszenierung

Mysite-Prod

Schritt 2

ein. Gehen Sie zu dem Standard, den Sie als Standard festlegen möchten (z. B. dev).

b. Lauffirebase deploy

c. Nach der Bereitstellung ausführenfirebase use --add

d. Es wird eine Option angezeigt, mit der Sie aus den verschiedenen Projekten auswählen können, die Sie derzeit haben.

Scrollen Sie zu dem Projekt, das Sie hinzufügen möchten: mysite-staging , und wählen Sie es aus.

e. Sie werden dann nach einem Alias ​​für dieses Projekt gefragt. Geben Sie Staging .

Führen Sie die Elemente ae erneut für prod und dev aus, damit jede Umgebung einen Alias ​​hat

Wissen Sie, in welcher Umgebung Sie sich befinden

Lauf firebase use default (mysite-dev)

* dev (mysite-dev)

staging (mysite-staging)

prod (mysite-dev)

(In einer der Umgebungen befindet sich links davon ein Sternchen. Dies ist das Sternchen, in dem Sie sich gerade befinden. Es wird auch blau hervorgehoben.)

Wechseln Sie zwischen Umgebungen

Laufen Sie firebase use stagingoder firebase use prodbewegen Sie sich zwischen ihnen.

Sobald Sie sich in der gewünschten Umgebung befinden, führen Sie sie aus firebase deployund Ihr Projekt wird dort bereitgestellt.

Hier sind ein paar hilfreiche Links ...

CLI-Referenz

Bereitstellung in mehreren Umgebungen

Hoffe das hilft.

Die Art und Weise, wie wir dies tun, besteht darin, verschiedene JSON-Schlüsseldateien für verschiedene Umgebungen zu erstellen. Wir haben die von Google empfohlene Funktion für Dienstkonten verwendet und haben eine Entwicklungsdatei und eine andere für die Produktion

Erstellen Sie das Tow-Projekt mit Dev und Produktionsumgebung auf der Firebase. Laden Sie die JSON-Datei von thre herunter

und richten Sie das SDK gemäß https://firebase.google.com/docs/android/setup oder für Crashlytics ein: https://firebase.google.com/docs/crashlytics/get-started?platform=android

Platzieren Sie zunächst die entsprechende Datei google_services.json für jeden buildType an den folgenden Speicherorten:

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

Hinweis: Root-App / google_services.json Diese Datei sollte gemäß den Build-Varianten vorhanden sein. Kopieren Sie den JSON-Code in die Root-JSON-Datei

Lassen Sie uns nun einige Gradle-Aufgaben in build.gradle Ihrer App ausführen, um das Verschieben der entsprechenden Datei google_services.json nach app / google_services.json zu automatisieren

Kopieren Sie dies in die App / Gradle-Datei

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

Großartig - aber diese Aufgaben manuell ausführen zu müssen, bevor Sie Ihre App erstellen, ist umständlich. Wir möchten, dass die oben genannte Kopieraufgabe irgendwann ausgeführt wird: assembleDebug oder: assembleRelease wird ausgeführt. Mal sehen, was passiert, wenn: assembleRelease ausgeführt wird: Kopieren Sie dieses in die Datei / gradlew

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

Beachten Sie die Aufgabe: app: processReleaseGoogleServices. Diese Aufgabe ist für die Verarbeitung der Stammdatei google_services.json verantwortlich. Wir möchten, dass die korrekte Datei google_services.json verarbeitet wird, daher müssen wir unsere Kopieraufgabe sofort im Voraus ausführen. Fügen Sie dies Ihrem build.gradle hinzu. Beachten Sie das AfterEvaluate-Gehäuse.

Kopieren Sie dies in die App / Gradle-Datei

afterEvaluate {
processDebugGoogleServices.dependsOn switchToDebug
processReleaseGoogleServices.dependsOn switchToRelease
}

Jetzt wird jederzeit aufgerufen: app: processReleaseGoogleServices, unsere neu definierte: app: switchToRelease wird vorher aufgerufen. Gleiche Logik für das Debuggen von buildType. Sie können Folgendes ausführen: app: assembleRelease und die Release-Version google_services.json werden automatisch in den Stammordner Ihres App-Moduls kopiert.