Environnement Firebase de développement et de production séparé

J'envisage d'utiliser Firebase comme MBaaS, mais je n'ai pas trouvé de solution fiable au problème suivant:

Je voudrais configurer deux environnements Firebase séparés, un pour le développement et un pour la production, mais je ne veux pas faire de copie manuelle des fonctionnalités (par exemple, configuration de la configuration à distance, règles de notification, etc.) entre l'environnement de développement et de production .

Existe-t-il un outil ou une méthode sur lequel je peux compter? La configuration à distance de règles de configuration ou de notification à partir de zéro peut être une tâche ardue et trop risquée.

Aucune suggestion? Y a-t-il une meilleure approche que d'avoir deux environnements séparés?

Avant de poster une autre réponse à la question qui explique comment configurer des comptes Firebase séparés: ce n'est pas la question, relisez-la. La question est: comment TRANSFÉRER les modifications entre des comptes de développement et de production séparés ou toute meilleure solution que de copier manuellement entre eux.

Comme tout le monde l'a souligné, vous avez besoin de plus d'un projet / base de données.

Mais pour répondre à votre question concernant la nécessité de pouvoir copier les paramètres / données, etc. du développement à la production. J'avais exactement le même besoin. Quelques mois de développement et de test, je ne voulais pas copier manuellement les données.

Mon résultat était de sauvegarder les données dans un compartiment de stockage, puis de les restaurer à partir de là dans l'autre base de données. C'est une façon assez grossière de le faire - et j'ai fait une sauvegarde / restauration complète de la base de données - mais vous pourrez peut-être regarder dans cette direction pour une manière plus contrôlée. Je ne l'ai pas utilisé - c'est très nouveau - mais cela pourrait être une solution: Module NPM firestore-export-import

Edit : Firestore backup / export / import info here Cloud Firestore Exporting and Importing Data

Si vous utilisez Firebase RTDB et non Firestore, cette documentation peut vous aider: Firebase Automated Backups

Vous devrez définir correctement les autorisations pour permettre à votre base de données de production d'accéder au même compartiment de stockage que votre développement. Bonne chance.

Si vous utilisez firebase-tools, il existe une commande firebase usequi vous permet de définir le projet que vous utilisez pourfirebase deploy

firebase use --addfera apparaître une liste de vos projets, sélectionnez-en un et il vous demandera un alias. De là, vous pouvezfirebase use alias et firebase deploypousserez vers ce projet.

Dans mon utilisation personnelle, j'ai my-app et my-app-dev en tant que projets dans la console Firebase.

Je n'utilise pas Firebase actuellement, mais je le considère comme vous. On dirait que la solution consiste à créer un projet complètement séparé sur la console. Il y avait un article de blog recommandant cela sur l'ancien site Firebase, qui semble être supprimé maintenant. https://web.archive.org/web/20160310115701/https://www.firebase.com/blog/2015-10-29-managing-development-environments.html

Aussi cette discussion recommandant la même chose: https://groups.google.com/forum/#!msg/firebase-talk/L7ajIJoHPcA/7dsNUTDlyRYJ

La façon dont je l'ai fait:

1. J'ai eu 2 projets sur firebase - un pour DEV, l'autre pour PROD
2. Localement, mon application avait également 2 branches - l'une nommée DEV, l'autre nommée PROD
3. Dans ma branche DEV, j'ai toujours le fichier JSON du projet DEV firebase et de même pour PROD

De cette façon, je ne suis pas obligé de maintenir mes JSON.

Cet article de blog décrit une approche très simple avec un type de version de débogage et de publication.

En un mot:

• Créez une nouvelle application sur Firebase pour chaque type de build en utilisant un suffixe d'ID d'application différent.
• Configurez votre projet Android avec le dernier fichier JSON.
• À l'aide de applicationIdSuffix, modifiez l'ID d'application pour qu'il corresponde aux différentes applications sur Firebase en fonction du type de build.

=> voir le blog pour une description détaillée.

Si vous souhaitez utiliser différentes saveurs de build, lisez ce blog complet sur le blog officiel de firebase. Il contient de nombreuses informations précieuses.

J'espère que cela pourra aider!

Vous devrez gérer différents types de build

Suivez ceci

1. Tout d'abord, créez un nouveau projet sur la console Firebase, nommez l'id comme YOURAPPNAME-DEV

2. Cliquez sur le bouton "Ajouter une application Android" et créez une nouvelle application. Nommez-le com.yourapp.debug, par exemple. Le nouveau fichier google-services.json sera téléchargé automatiquement

3. Dans le répertoire src de votre projet, créez un nouveau répertoire avec le nom "debug" et copiez le nouveau fichier google-services.json ici

4. Dans votre module build.gradle, ajoutez ceci

   debug {
           applicationIdSuffix ".debug"
       }
   

Maintenant, lorsque vous construisez une compilation de débogage, google-services.json à partir du dossier "debug" sera utilisé et lorsque vous construirez en mode version, google-services.json à partir du répertoire racine du module sera pris en compte.

Pour résoudre ce problème dans ma situation, j'ai créé trois projets Firebase, chacun avec le même projet Android (c'est-à-dire le même applicationIdsans utiliser les applicationIdSuffixsuggestions des autres). Cela a abouti à trois fichiers google-services.json que j'ai stockés sur mon serveur d'intégration continue (CI) en tant que variables d'environnement personnalisées . Pour chaque étape de la construction (dev / staging / prod), j'ai utilisé le fichier google-services.json correspondant.

Pour le projet Firebase associé à dev, dans son projet Android, j'ai ajouté l'empreinte du certificat de débogage SHA. Mais pour la préparation et la production, je demande simplement à CI de signer l'APK.

Voici un dépouillé .gitlab-ci.ymlqui a fonctionné pour cette configuration:

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

Je suis satisfait de cette solution car elle ne repose pas sur des astuces build.gradle que je trouve trop opaques et donc difficiles à maintenir. Par exemple, lorsque j'ai essayé les approches utilisant applicationIdSuffixet différents buildTypes, j'ai constaté que je ne pouvais pas exécuter de tests instrumentés ni même compiler lorsque j'essayais de changer de type de construction en utilisant testBuildType. Android semblait donner des propriétés spéciales au debug buildTypeque je ne pouvais pas inspecter pour comprendre.

Pratiquement, les scrips CI sont assez transparents et faciles à maintenir, d'après mon expérience. En effet, l'approche que j'ai décrite a fonctionné: lorsque j'ai exécuté chacun des APK générés par CI sur un émulateur, l'étape «Exécutez votre application pour vérifier l'installation» de la console Firebase est passée de

Vérifier si l'application a communiqué avec nos serveurs. Vous devrez peut-être désinstaller et réinstaller votre application.

à:

Félicitations, vous avez ajouté Firebase à votre application avec succès!

pour les trois applications lorsque je les ai démarrées une par une dans un émulateur.

Firebase a une page à ce sujet qui explique comment le configurer pour le développement et la production

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

Définir la configuration de l'environnement pour votre projet Pour stocker les données d'environnement, vous pouvez utiliser les fonctions de Firebase: commande config: set dans Firebase CLI. Chaque clé peut être nommée à l'aide de points pour regrouper la configuration associée. Gardez à l'esprit que seuls les caractères minuscules sont acceptés dans les clés; les caractères majuscules ne sont pas autorisés.

Par exemple, pour stocker l'ID client et la clé API de "Some Service", vous pouvez exécuter:

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

Récupérer la configuration actuelle de l'environnement Pour inspecter ce qui est actuellement stocké dans la configuration de l'environnement pour votre projet, vous pouvez utiliser les fonctions de firebase: config: get. Il produira quelque chose de JSON comme ceci:

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

Je mets à jour cette réponse en fonction des informations que je viens de trouver.

Étape 1

Dans firebase.google.com, créez vos multiples environnements (par exemple, dev, staging, prod)

mysite-dev

mise en scène de mysite

mysite-prod

Étape 2

une. Déplacez-vous directement vers celui que vous voulez être votre valeur par défaut (c.-à-d. Dev)

b. Courirfirebase deploy

c. Une fois déployé, exécutezfirebase use --add

ré. Une option apparaîtra pour sélectionner parmi les différents projets que vous avez actuellement.

Faites défiler jusqu'au projet que vous souhaitez ajouter: mysite-staging , et sélectionnez-le.

e. Il vous sera alors demandé un alias pour ce projet. Entrez la mise en scène .

Exécutez à nouveau les éléments ae pour prod et dev, afin que chaque environnement ait un alias

Sachez dans quel environnement vous vous trouvez

Courir firebase use default (mysite-dev)

* dev (mysite-dev)

staging (mysite-staging)

prod (mysite-dev)

(l'un des environnements aura un astérisque à gauche. C'est celui dans lequel vous vous trouvez actuellement. Il sera également surligné en bleu)

Basculer entre les environnements

Courez firebase use stagingou firebase use prodpour vous déplacer entre eux.

Une fois que vous êtes dans l'environnement souhaité, exécutez firebase deployet votre projet y sera déployé.

Voici quelques liens utiles ...

Référence CLI

Déploiement dans plusieurs environnements

J'espère que cela t'aides.

La façon dont nous le faisons est de créer différents fichiers de clé json pour différents environnements. Nous avons utilisé la fonctionnalité de compte de service comme recommandé par Google et avons un fichier de développement et un autre pour la production

Créez le projet Tow avec l'environnement de développement et de production sur la base de feu Téléchargez le fichier json à partir de trois

et configurez le SDK selon: https://firebase.google.com/docs/android/setup Ou pour Crashlytics: https://firebase.google.com/docs/crashlytics/get-started?platform=android

Tout d'abord, placez le google_services.json respectif pour chaque buildType aux emplacements suivants:

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

Remarque: Root app / google_services.json Ce fichier devrait être là selon les variantes de construction copiez le code json dans le fichier json racine

Maintenant, passons en revue certaines tâches de gradle dans votre: app's build.gradle pour automatiser le déplacement du google_services.json approprié vers app / google_services.json

copiez-le dans le fichier 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 "."
}

Excellent - mais il est fastidieux de devoir exécuter manuellement ces tâches avant de créer votre application. Nous voudrions que la tâche de copie appropriée ci-dessus soit exécutée quelque temps avant: assembleDebug ou: assembleRelease est exécuté. Voyons ce qui se passe lorsque: assembleRelease est exécuté: copiez celui-ci dans le fichier / gradlew

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

Notez la tâche: app: processReleaseGoogleServices. Cette tâche est responsable du traitement du fichier racine google_services.json. Nous voulons que le google_services.json correct soit traité, nous devons donc exécuter notre tâche de copie immédiatement avant. Ajoutez ceci à votre build.gradle. Notez l'afterEvaluate englobant.

copiez-le dans le fichier app / Gradle

afterEvaluate {
processDebugGoogleServices.dependsOn switchToDebug
processReleaseGoogleServices.dependsOn switchToRelease
}

Désormais, à tout moment: app: processReleaseGoogleServices est appelé, notre nouveau: app: switchToRelease sera appelé au préalable. Même logique pour le buildType de débogage. Vous pouvez exécuter: app: assembleRelease et la version de sortie google_services.json sera automatiquement copiée dans le dossier racine de votre module d'application.