Separare l'ambiente di sviluppo e sviluppo Firebase

Sto pensando di utilizzare Firebase come MBaaS, tuttavia non sono riuscito a trovare alcuna soluzione affidabile al seguente problema:

Vorrei impostare due ambienti Firebase separati, uno per lo sviluppo e uno per la produzione, ma non voglio fare una copia manuale delle funzionalità (ad es. Configurazione della configurazione remota, regole di notifica, ecc.) Tra l'ambiente di sviluppo e di produzione .

Esiste uno strumento o un metodo su cui posso fare affidamento? L'impostazione da zero della configurazione remota o delle regole di notifica può essere un'attività scoraggiante e troppo rischiosa.

Eventuali suggerimenti? Esiste un approccio migliore rispetto ad avere due ambienti separati?

Prima di pubblicare un'altra risposta alla domanda che spiega come configurare account Firebase separati: non è la domanda, leggila di nuovo. La domanda è: come TRASFERIRE le modifiche tra account dev e prod separati o qualsiasi soluzione migliore rispetto alla copia manuale tra di loro.

Come tutti hanno sottolineato, è necessario più di un progetto / database.

Ma per rispondere alla tua domanda in merito alla necessità di poter copiare impostazioni / dati ecc. Dallo sviluppo alla produzione. Ho avuto esattamente lo stesso bisogno. Alcuni mesi di sviluppo e test, non volevo copiare manualmente i dati.

Il mio risultato è stato il backup dei dati su un bucket di archiviazione, quindi ripristinarli da lì nell'altro database. È un modo piuttosto grezzo per farlo - e ho fatto un intero backup / ripristino del database - ma potresti essere in grado di cercare in quella direzione un modo più controllato. Non l'ho usato - è molto nuovo - ma questa potrebbe essere una soluzione: modulo NPM firestore-export-import

Modifica : backup Firestore / esportazione / importazione informazioni qui Cloud Firestore Esportazione e importazione di dati

Se si utilizza Firebase RTDB e non Firestore, questa documentazione potrebbe essere utile: Backup automatici Firebase

Sarà necessario impostare correttamente le autorizzazioni per consentire al database di produzione di accedere allo stesso bucket di archiviazione dello sviluppo. In bocca al lupo.

Se stai usando firebase-tools c'è un comando firebase useche ti consente di impostare per quale progetto stai usandofirebase deploy

firebase use --addmostrerà un elenco dei tuoi progetti, selezionane uno e ti chiederà un alias. Da lì puoi firebase use aliase firebase deployspingerai a quel progetto.

Nel mio uso personale, ho my-app e my-app-dev come progetti nella console di Firebase.

Al momento non sto usando Firebase, ma lo considero come te. Sembra che la strada da percorrere sia creare un progetto completamente separato sulla console. C'era un post sul blog che lo consigliava sul vecchio sito Firebase, ma sembra essere rimosso ora. https://web.archive.org/web/20160310115701/https://www.firebase.com/blog/2015-10-29-managing-development-environments.html

Anche questa discussione raccomanda lo stesso: https://groups.google.com/forum/#!msg/firebase-talk/L7ajIJoHPcA/7dsNUTDlyRYJ

Il modo in cui l'ho fatto:

1. Ho avuto 2 progetti su Firebase, uno per DEV e altri per PROD
2. A livello locale la mia app aveva anche 2 rami: uno chiamato DEV, l'altro chiamato PROD
3. Nel mio ramo DEV ho sempre un file JSON del progetto Firebase DEV e similmente per PROD

In questo modo non sono tenuto a conservare i miei JSON.

Questo post sul blog descrive un approccio molto semplice con un tipo di build di debug e release.

In breve:

• Crea una nuova app su Firebase per ogni tipo di build utilizzando un suffisso ID applicazione diverso.
• Configura il tuo progetto Android con l'ultimo file JSON.
• Utilizzando applicationIdSuffix, modifica l'ID applicazione in modo che corrisponda alle diverse app su Firebase in base al tipo di build.

=> vedi il blogpost per una descrizione dettagliata.

Se si desidera utilizzare diversi tipi di build, leggere questo ampio post sul blog ufficiale di Firebase. Contiene molte informazioni preziose.

Spero che aiuti!

Dovrai gestire diversi tipi di build

Segui questo

1. Innanzitutto, crea un nuovo progetto sulla console di Firebase, id nome come YOURAPPNAME-DEV

2. Fai clic sul pulsante "Aggiungi app Android" e crea una nuova app. Chiamalo com.yourapp.debug, per esempio. Il nuovo file google-services.json verrà scaricato automaticamente

3. Nella tua directory di progetto src crea una nuova directory con il nome "debug" e copia qui il nuovo file google-services.json

4. A livello di modulo build.gradle aggiungi questo

   debug {
           applicationIdSuffix ".debug"
       }
   

Ora quando si crea una build di debug verrà utilizzato google-services.json dalla cartella "debug" e quando si costruirà in modalità di rilascio verrà considerato google-services.json dalla directory principale del modulo.

Per risolvere questo problema, ho creato tre progetti Firebase, ciascuno con lo stesso progetto Android (ovvero lo stesso applicationIdsenza utilizzare quello applicationIdSuffixsuggerito da altri). Ciò ha comportato tre file google-services.json che ho archiviato nel mio server di integrazione continua (CI) come variabili di ambiente personalizzate . Per ogni fase della build (dev / staging / prod), ho usato il file google-services.json corrispondente.

Per il progetto Firebase associato a dev, nel suo progetto Android, ho aggiunto l'impronta digitale del certificato SHA di debug. Ma per la messa in scena e la prodezza ho appena firmato CI APK.

Ecco una versione ridotta .gitlab-ci.ymlche ha funzionato per questa configurazione:

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

Sono contento di questa soluzione perché non si basa su trucchi build.gradle che credo siano troppo opachi e quindi difficili da mantenere. Ad esempio, quando ho provato gli approcci usando applicationIdSuffixe diversi buildTypes ho scoperto che non ero in grado di eseguire test strumentali da eseguire o addirittura compilare quando ho provato a cambiare i tipi di build usando testBuildType. Android sembrava dare proprietà speciali alle debug buildTypequali non riuscivo a controllare per capire.

Virtualmente, gli script CI sono abbastanza trasparenti e facili da mantenere, nella mia esperienza. In effetti, l'approccio che ho descritto ha funzionato: quando ho eseguito ciascuno degli APK generati da CI su un emulatore, il passaggio "Esegui la tua app per verificare l'installazione" della console Firebase è passato da

Verifica se l'app ha comunicato con i nostri server. Potrebbe essere necessario disinstallare e reinstallare l'app.

per:

Congratulazioni, hai aggiunto correttamente Firebase alla tua app!

per tutte e tre le app quando le ho avviate una ad una in un emulatore.

Firebase ha una pagina su questo che spiega come configurarlo per dev e prod

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

Imposta la configurazione dell'ambiente per il tuo progetto Per archiviare i dati dell'ambiente, puoi usare le funzioni firebase: config: imposta il comando nella CLI di Firebase. Ogni chiave può essere spaziata utilizzando i punti per raggruppare insieme la configurazione correlata. Tieni presente che nelle chiavi sono accettati solo caratteri minuscoli; i caratteri maiuscoli non sono ammessi.

Ad esempio, per memorizzare l'ID client e la chiave API per "Alcuni servizi", è possibile eseguire:

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

Recupera la configurazione dell'ambiente corrente Per controllare ciò che è attualmente archiviato nella configurazione dell'ambiente per il progetto, è possibile utilizzare le funzioni firebase: config: get. Produrrà qualcosa di simile a JSON:

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

Sto aggiornando questa risposta in base alle informazioni che ho appena trovato.

Passo 1

In firebase.google.com, crea i tuoi ambienti multipli (ad esempio, sviluppo, messa in scena, prod)

miosito-dev

miosito-messa in scena

miosito-prod

Passo 2

un. Passa direttamente al valore predefinito (ad esempio; dev)

b. Correrefirebase deploy

c. Una volta distribuito, eseguifirebase use --add

d. Verrà visualizzata un'opzione per selezionare tra i diversi progetti che hai attualmente.

Scorri fino al progetto che desideri aggiungere: mysite-staging e selezionalo.

e. Ti verrà quindi chiesto un alias per quel progetto. Inserisci la messa in scena .

Esegui nuovamente gli elementi per prod e dev, in modo che ogni ambiente abbia un alias

Scopri in quale ambiente ti trovi

Correre firebase use default (mysite-dev)

* dev (mysite-dev)

staging (mysite-staging)

prod (mysite-dev)

(uno degli ambienti avrà un asterisco alla sua sinistra. È quello in cui ci si trova attualmente. Verrà anche evidenziato in blu)

Passa da un ambiente all'altro

Corri firebase use stagingo firebase use prodper spostarti tra di loro.

Una volta che sei nell'ambiente che desideri, esegui firebase deploye il tuo progetto verrà distribuito lì.

Ecco un paio di link utili ...

Riferimento CLI

Distribuzione in più ambienti

Spero che questo ti aiuti.

Il modo in cui lo stiamo facendo è creando diversi file chiave json per ambienti diversi. Abbiamo utilizzato la funzionalità dell'account di servizio come raccomandato da google e abbiamo un file di sviluppo e un altro per la produzione

Crea il progetto Tow con Dev e l'ambiente di produzione sulla base del fuoco Scarica il file json da tre

e imposta l'SDK come da: https://firebase.google.com/docs/android/setup O per Crashlytics: https://firebase.google.com/docs/crashlytics/get-started?platform=android

Innanzitutto, posiziona il rispettivo google_services.json per ciascun buildType nelle seguenti posizioni:

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

Nota: app root / google_services.json Questo file dovrebbe trovarsi lì in base alle varianti di build, copiare il codice json nel file json root

Ora, eseguiamo alcune attività graduali nel tuo: build.gradle dell'app per automatizzare lo spostamento del google_services.json appropriato in app / google_services.json

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

Fantastico, ma dover eseguire manualmente queste attività prima di creare l'app è complicato. Vorremmo che l'attività di copia appropriata sopra fosse eseguita qualche tempo prima: assembleDebug o: assembleRelease è in esecuzione. Vediamo cosa succede quando: assembleRelease viene eseguito: copia questo nel file / gradlew

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

Nota l'attività: app: processReleaseGoogleServices. Questa attività è responsabile dell'elaborazione del file root google_services.json. Vogliamo che il corretto google_services.json venga elaborato, quindi dobbiamo eseguire immediatamente la nostra attività di copia. Aggiungi questo al tuo build.gradle. Nota la valutazione after aftervaluate.

copiarlo nel file app / Gradle

afterEvaluate {
processDebugGoogleServices.dependsOn switchToDebug
processReleaseGoogleServices.dependsOn switchToRelease
}

Ora, in qualsiasi momento: app: processReleaseGoogleServices viene chiamato, la nostra nuova definizione: app: switchToRelease verrà chiamata in anticipo. Stessa logica per il debug buildType. Puoi eseguire: app: assembleRelease e la versione di rilascio google_services.json verrà automaticamente copiata nella cartella principale del modulo dell'app.