Я подумываю об использовании Firebase в качестве MBaaS, однако мне не удалось найти надежного решения следующей проблемы:

Я хотел бы настроить две отдельные среды Firebase, одну для разработки и одну для производства, но я не хочу вручную копировать функции (например, удаленную настройку конфигурации, правила уведомлений и т. Д.) Между среда разработки и производства.

Есть ли какой-нибудь инструмент или метод, на которые я могу положиться? Настройка удаленной конфигурации или правил уведомлений с нуля может быть сложной задачей и слишком рискованной.

Есть предложения? Есть ли лучший подход, чем наличие двух отдельных сред?

Прежде чем опубликовать еще один ответ на вопрос, в котором объясняется, как настроить отдельные учетные записи Firebase: это не вопрос, прочтите его еще раз. Возникает вопрос: как ПЕРЕНОСИТЬ изменения между отдельными учетными записями dev и prod или любое лучшее решение, чем ручное копирование между ними.

Ответы (12)

Как все отметили - вам нужно более одного проекта / базы данных.

Но отвечу на ваш вопрос о необходимости иметь возможность копировать настройки / данные и т. Д. Из разработки в продакшн. У меня была точно такая же потребность. Несколько месяцев разработки и тестирования, я не хотел вручную копировать данные.

В результате я сделал резервную копию данных в хранилище, а затем восстановил их оттуда в другую базу данных. Это довольно грубый способ сделать это - и я сделал полную резервную копию / восстановление базы данных - но вы могли бы поискать более контролируемый способ в этом направлении. Я не использовал его - он очень новый - но это может быть решением: NPM Module firestore-export-import

Редактировать: здесь информация о резервном копировании / экспорте / импорте Firestore Экспорт и импорт данных Cloud Firestore

Если вы используете Firebase RTDB, а не Firestore, эта документация может помочь: Автоматическое резервное копирование Firebase

Вам нужно будет правильно установить разрешения, чтобы ваша производственная база данных могла получить доступ к тому же сегменту хранилища, что и ваша разработка. Удачи.

Как я это сделал:

  1. У меня было 2 проекта на firebase - один для DEV, другой для PROD
  2. Локально у моего приложения также было 2 ветки - одна с именем DEV, другая с именем PROD
  3. В моей ветке DEV у меня всегда есть JSON-файл проекта DEV firebase, а также для PROD

Таким образом, мне не нужно поддерживать свои JSON.

Этот блог описывает очень простой подход с типом сборки отладки и выпуска.

В двух словах:

  • Создайте новое приложение в Firebase для каждого типа сборки, используя другой суффикс идентификатора приложения.
  • Настройте свой проект Android с использованием последней версии файла JSON.
  • Используя applicationIdSuffix, измените идентификатор приложения, чтобы он соответствовал различным приложениям в Firebase, в зависимости от типа сборки.

=> подробное описание см. В блоге.

Если вы хотите использовать разные варианты сборки, прочтите этот обширный блог из официального блога firebase. В нем много ценной информации.

Надеюсь, что это поможет!

Чтобы решить эту проблему в моей ситуации, я создал три проекта Firebase, каждый с одним и тем же проектом Android (то есть с одним и тем же applicationId без использования applicationIdSuffix, предложенного другими). Это привело к появлению трех файлов google-services.json, которые я сохранил на моем сервере непрерывной интеграции (CI) как пользовательские переменные среды. Для каждого этапа сборки (dev / staging / prod) я использовал соответствующий файл google-services.json.

Для проекта Firebase, связанного с dev, в его проекте Android я добавил отпечаток сертификата SHA отладки. Но для постановки и продакшена у меня просто CI подписал APK.

Вот урезанный .gitlab-ci.yml, который работал для этой настройки:

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

Я доволен этим решением, потому что оно не полагается на уловки build.gradle, которые, как мне кажется, слишком непрозрачны и поэтому их сложно поддерживать. Например, когда я пробовал подходы с использованием applicationIdSuffix и различных buildTypes, я обнаружил, что не могу запустить или даже скомпилировать инструментальные тесты, когда я пытался переключить типы сборки с помощью testBuildType. Android, похоже, придал особые свойства debug buildType, которые я не мог понять, чтобы понять.

По моему опыту, сценарии CI довольно прозрачны и просты в обслуживании. Действительно, описанный мной подход сработал: когда я запускал каждый из APK-файлов, сгенерированных CI, на эмуляторе, шаг консоли Firebase «Запустите приложение для проверки установки» изменился с

Проверка, связывалось ли приложение с нашими серверами. Возможно, вам придется удалить и переустановить приложение.

на:

Поздравляем, вы успешно добавили Firebase в свое приложение!

для всех трех приложений, поскольку я запускал их одно за другим в эмуляторе.

Создайте проект Tow с Dev и производственной средой на базе firebase Загрузите файл json с сайта

и настройте SDK в соответствии с: https://firebase.google.com/docs/android/setup Или для Crashlytics: https://firebase.google.com/docs/crashlytics/get-started?platform=android

Сначала поместите соответствующий файл google_services.json для каждого buildType в следующие места:

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

Примечание: Root app / google_services.json Этот файл должен быть там в соответствии с вариантами сборки, скопируйте код json в корневой файл json

Теперь давайте создадим несколько задач gradle в build.gradle вашего: app, чтобы автоматизировать перемещение соответствующего google_services.json в app / google_services.json

скопируйте это в файл 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 "."
}

Отлично, но необходимость вручную запускать эти задачи перед сборкой приложения является обременительной. Мы бы хотели, чтобы соответствующая задача копирования, описанная выше, выполнялась когда-нибудь до того, как будет запущена: assemblyDebug или: assemblyRelease. Давайте посмотрим, что произойдет, когда: AssemblyRelease запускается: скопируйте это в файл / gradlew

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

Обратите внимание на задачу: app: processReleaseGoogleServices. Эта задача отвечает за обработку корневого файла google_services.json. Мы хотим, чтобы был обработан правильный файл google_services.json, поэтому мы должны немедленно запустить нашу задачу копирования. Добавьте это в свой build.gradle. Обратите внимание на заключительный элемент afterEvaluate.

скопируйте это в файл app / Gradle

afterEvaluate {
processDebugGoogleServices.dependsOn switchToDebug
processReleaseGoogleServices.dependsOn switchToRelease
}

Теперь, когда вызывается: app: processReleaseGoogleServices, заранее будет вызываться наш недавно определенный: app: switchToRelease. Та же логика для отладки buildType. Вы можете запустить: app: assemblyRelease, и окончательная версия google_services.json будет автоматически скопирована в корневую папку вашего модуля приложения.

Я обновляю этот ответ на основе информации, которую я только что нашел.

Шаг 1

На firebase.google.com создайте несколько сред (например, dev, staging, prod)


mysite-dev

mysite-staging

mysite-prod


Шаг 2

а. Перейдите к тому, которое вы хотите использовать по умолчанию (например, dev)

б. Запустите firebase deploy

с. После развертывания запустите firebase use --add

д. Появится возможность выбрать из различных проектов, которые у вас есть в настоящее время.

Прокрутите до проекта, который хотите добавить: mysite-staging, и выберите его.

эл. Затем вас попросят указать псевдоним для этого проекта. Введите постановка.

Снова запустите элементы a-e для prod и dev, чтобы у каждой среды был псевдоним


Знайте, в какой среде вы находитесь

запустить использовать firebase по умолчанию (mysite-dev)

* разработчик (mysite-dev)

стадия (mysite-staging)

продукт (mysite-dev)

(слева от одной из сред будет звездочка. Это та среда, в которой вы сейчас находитесь. Она также будет выделена синим)


Переключение между средами

Run firebase использовать staging или firebase использовать prod для перемещения между ними.

Как только вы окажетесь в нужной среде, запустите firebase deploy, и ваш проект будет развернут там.

Вот пара полезных ссылок ...

Ссылка CLI

Развертывание в нескольких средах

Надеюсь, это поможет.

В настоящее время я не использую Firebase, но считаю, что это как и вы. Похоже, что лучше всего создать на консоли совершенно отдельный проект. На старом сайте Firebase был опубликован пост в блоге, в котором это рекомендовалось, но сейчас его нужно удалить.https://web.archive.org/web/20160310115701/https: //www.firebase.com/blog/2015-10-29-managing-development-environments.html

Также это обсуждение рекомендует то же самое: https://groups.google.com/forum/#! msg / firebase-talk / L7ajIJoHPcA / 7dsNUTDlyRYJ

Мы решили запускать экземпляры нового эмулятора Firebase на локальном сервере разработки для Test и UAT, полностью исключив GCP из поля зрения. Он разработан именно для этого варианта использования.

https://firebase.google.com/docs/emulator-suite

У Firebase есть страница об этом, где рассказывается, как настроить его для разработчиков и продуктов

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

Установить конфигурацию среды для вашего проекта Для хранения среды data, вы можете использовать команду firebase functions: config: set в Интерфейс командной строки Firebase. Каждому ключу можно присвоить пространство имен, используя точки для группировки. связанные конфигурации вместе. Имейте в виду, что только строчные буквы в ключах принимаются символы; Заглавные буквы не допускаются.

Например, чтобы сохранить идентификатор клиента и ключ API для «Некоторая услуга», вы можете запустить:

функции firebase: config: set someservice.key = "КЛЮЧ API" someservice.id = "ИД КЛИЕНТА"

Получить текущую конфигурацию среды Чтобы проверить, что в настоящее время хранится в конфигурации среды для вашего проекта, вы можете использовать firebase функции: config: get. Он выведет JSON примерно так:

{
  "someservice": {
    "key": "КЛЮЧ API",
    "id": "ИД КЛИЕНТА"
  }
}

Если вы используете firebase-tools, есть команда firebase use, которая позволяет вам указать, какой проект вы используете для развертывания firebase

firebase use --add откроет список ваших проектов, выберите один и запросит псевдоним. Оттуда вы можете использовать псевдоним firebase, а firebase deploy отправит в этот проект.

В моем личном использовании у меня есть проекты my-app и my-app-dev в консоли Firebase.

Мы делаем это, создавая разные файлы ключей json для разных сред. Мы использовали функцию служебной учетной записи в соответствии с рекомендациями Google, и у нас есть один файл для разработки, а другой - для производства

enter image description here

Вам нужно будет управлять разными типами сборки

Следуйте этому

  1. Сначала создайте новый проект в консоли Firebase, назовите id как YOURAPPNAME-DEV

  2. Нажмите кнопку «Добавить приложение для Android» и создайте новое приложение. Назовите его, например, com.yourapp.debug. Новый файл google-services.json будет загружаться автоматически

  3. В каталоге src вашего проекта создайте новый каталог с именем «debug» и скопируйте сюда новый файл google-services.json

  4. На уровне вашего модуля build.gradle добавьте это

    отладка {
            applicationIdSuffix ".debug"
        }
    

Теперь при сборке отладочной сборки будет использоваться google-services.json из папки «debug», а при сборке в режиме выпуска будет учитываться google-services.json из корневого каталога модуля.

2022 WebDevInsider