web-dev-qa-db-fra.com

Environnement Firebase distinct pour les développeurs et les développeurs

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

Je souhaite configurer deux environnements Firebase distincts, un pour le développement et un pour la production, mais je ne souhaite pas effectuer de copie manuelle des fonctionnalités (par exemple, 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? Configurer la configuration à distance ou les règles de notification à partir de zéro peut être une tâche décourageante 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 distincts: lisez-la à nouveau. La question qui se pose est la suivante: comment TRANSFÉRER change entre des comptes de développement et de production séparés, ou une meilleure solution que la copie manuelle entre eux.

firebase
85
racs

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'ai eu exactement le même besoin. Quelques mois de développement et de test, je ne voulais pas copier les données manuellement.

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 rudimentaire de le faire - et j'ai effectué une sauvegarde/restauration de base de données complète - mais vous pourrez peut-être chercher dans cette direction un moyen plus contrôlé. Je ne l'ai pas utilisé - il est très nouveau - mais cela pourrait être une solution: NPM Module firestore-export-import

Modifier: Sauvegarde Firestore/Exporter/Importer les informations ici Cloud Firestore Exporter et importer des données

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

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

1
stevecowling

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

firebase use --add affichera une liste de vos projets, sélectionnez-en un et vous demandera un alias. De là, vous pouvez firebase use alias et firebase deploy pousser vers ce projet.

Dans mon utilisation personnelle, my-app et my-app-dev sont des projets de la console Firebase.

28
Lunchbox

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

Cette discussion recommande aussi la même chose: https://groups.google.com/forum/#!msg/firebase-talk/L7ajIJoHPcA/7dsNUTDlyRYJ

24
Patrick

Cet article de blog décrit une approche très simple avec un type de construction debug et release. 

En un mot:

  • Créez une nouvelle application sur Firebase pour chaque type de construction en utilisant un suffixe d'identification différent.
  • Configurez votre projet Android avec le dernier fichier JSON.
  • À l'aide de applicationIdSuffix, changez l'ID de l'application pour faire correspondre les différentes applications sur Firebase en fonction du type de construction.

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

Si vous voulez utiliser différentes versions de build, lisez ceci blogpost du blog officiel de firebase. Il contient beaucoup d'informations précieuses.

J'espère que cela pourra aider!

5
lukle

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 id par YOURAPPNAME-DEV.

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

  3. Dans votre répertoire src de projet, créez un nouveau répertoire portant 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 créez un débogage, google-services.json sera utilisé à partir du dossier "debug" et lorsque vous construirez en mode de publication, google-services.json à partir du répertoire racine du module sera pris en compte.

3
Chetan

La façon dont je l'ai fait:

  1. J'ai eu 2 projets sur firebase - un pour DEV autre pour PROD
  2. Localement, mon application comportait également 2 branches: l’une nommée DEV, l’autre nommée PROD.
  3. Dans ma branche DEV, j’ai toujours un fichier JSON du projet DEV firebase, ainsi que pour PROD.

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

1
Kunal Khaire

Firebase a une page sur cette page qui explique comment la configurer pour dev et prod

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

Définir la configuration de l’environnement de votre projet Pour stocker l’environnement données, vous pouvez utiliser les fonctions de Firebase: config: commande set dans le fichier CLI Firebase. Chaque touche peut être nommée en utilisant des points pour grouper configuration connexe ensemble. Gardez à l'esprit que seules les minuscules les caractères 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 pour "Some Service", vous pourriez courir:

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 de votre projet, vous pouvez utiliser firebase fonctions: config: get. JSON produira quelque chose comme ceci:

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

Pour ce faire, nous créons différents fichiers de clés Json pour différents environnements. Nous avons utilisé la fonctionnalité de compte de service recommandée par Google et disposons d’un fichier de développement et d’un autre

 enter image description here

0
vsingh

J'actualise cette réponse en fonction des informations que je viens de trouver.

Étape 1

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

mysite-dev

mysite-staging

mysite-prod

Étape 2

une. Déplacez-vous directement sur le paramètre que vous souhaitez utiliser par défaut (c'est-à-dire dev.)

b. Exécuter firebase deploy

c. Une fois déployé, lancez firebase 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. On vous demandera ensuite un alias pour ce projet. Entrez staging .

Exécutez à nouveau les éléments a-e pour prod et dev afin que chaque environnement ait un alias.

Sachez dans quel environnement vous vous trouvez

Exécutez firebase usedefault (mysite-dev)

* dev (mysite-dev)

staging (mysite-staging)

prod (mysite-dev)

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

Basculer entre les environnements

Exécutez firebase use staging ou firebase use prod pour vous déplacer entre eux.

Une fois que vous êtes dans l'environnement de votre choix, exécutez firebase deploy et votre projet s'y déploiera.

Voici quelques liens utiles ...

Référence CLI

déploiement dans plusieurs environnements

J'espère que cela t'aides.

0
webfrogs

Pour résoudre ce problème, j’ai créé trois projets Firebase, chacun avec le même projet Android (c’est-à-dire le même applicationId sans utiliser le applicationIdSuffix proposé par d’autres). Cela a abouti à trois fichiers google-services.json que j'ai stockés dans mon serveur 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 de certificat de débogage SHA. Mais pour la mise en scène et prod, je viens de CI signer le APK.

Voici un .gitlab-ci.yml simplifié qui 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
# https://stackoverflow.com/questions/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 crois trop opaques et donc difficiles à maintenir. Par exemple, lorsque j'ai essayé les approches utilisant applicationIdSuffix et différents buildTypes, j'ai constaté que je ne pouvais pas exécuter ni même compiler de tests instrumentés lorsque je tentais de changer de type de construction à l'aide de testBuildType. Android semblait donner des propriétés spéciales à la debugbuildType que je ne pouvais pas inspecter pour comprendre.

Virtuellement, les scripts CI sont cependant assez transparents et faciles à gérer, selon mon expérience. En effet, l'approche que j'ai décrite a fonctionné: lorsque j'ai exécuté chacun des fichiers 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!

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

0
Michael Osofsky