Отдельная среда разработки и разработки Firebase

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В настоящее время я не использую 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

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

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

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

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

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

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

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

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

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

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

Следить за этим

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

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

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

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

   debug {
           applicationIdSuffix ".debug"
       }
   

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

Чтобы решить эту проблему для моей ситуации, я создал три проекта Firebase, каждый с одним и тем же проектом Android (то есть applicationIdбез использования applicationIdSuffixпредложенных другими). В результате были получены три файла google-services.json, которые я сохранил на своем сервере Continuous Integration (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
# /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/

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

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

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

чтобы:

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

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

У Firebase есть страница по этому вопросу, в которой рассказывается, как настроить ее для dev и prod.

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

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

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

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

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

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

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

Шаг 1

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

MySite-DEV

MySite-стадирования

MySite-прод

Шаг 2

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

б. Бегатьfirebase deploy

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

д. Появится опция выбора из разных проектов, которые у вас есть.

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

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

Запустите элементы ae еще раз для prod и dev, чтобы у каждого окружения был псевдоним

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

Бегать firebase use default (mysite-dev)

* dev (mysite-dev)

staging (mysite-staging)

prod (mysite-dev)

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

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

Беги firebase use stagingили firebase use prodдвигайся между ними.

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

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

Справочник по CLI

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

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

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

Создайте проект 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.

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

скопируйте это в файл приложения / 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 или: executeRelease. Давайте посмотрим, что произойдет, когда: executeRelease запущен: скопируйте этот файл в файл / 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.

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

afterEvaluate {
processDebugGoogleServices.dependsOn switchToDebug
processReleaseGoogleServices.dependsOn switchToRelease
}

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