Миграция схемы Firestore между проектами

Question

У меня есть проект Firebase, который в основном имеет две среды: Staging и Production . Я организовал их, создав различные проекты Firebase. Каждый из моих проектов использует Облачные функции Firebase и Firestore . За исключением этого, у меня есть каждый из проектов, связанных с определенной веткой GIT. Обе ветви интегрированы в конвейер CI / CD в Google Cloud Build .

Итак, чтобы прояснить ситуацию, я поделюсь простой диаграммой:

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

1. Изменение схемы Firestore присутствует на Staging
2. Облачная функция (на Staging ) настроен на новую схему.
3. Объединение подготовка ответвление в производство .
4. Из-за старой схемы Firestore на production новые функции не будут работать должным образом.

Чтобы обойти ее, мне нужновручную перейти к экземпляру production Firestore и откорректировать там схему (есть риск испортить производственные данные).

В идеальном случае, эта операция была бы автоматизирована и существующий проектданные будут адаптированы к новой схеме, которая будет динамически вводиться после слияния.

Возможно ли это как-нибудь? Что-то вроде миграций в .NET Core .

Answer 1

Cloud Firestore не содержит схемы - документы не имеют принудительной схемы. Код может записывать любые поля, которые он хочет, в любое время. (Для веб-клиентов и мобильных клиентов это регулируется правилами безопасности, но для внутреннего кода ограничений нет.) Таким образом, в Cloud Firestore не существует формальной миграции.

Схема "«ваших документов эффективно определяется вашим кодом, который читает и записывает эти документы. Это означает, что миграция данных в новый формат означает, что вам нужно будет написать код для выполнения необходимых изменений. Там действительно нет простого способа обойти это. Все, что вы действительно можете сделать, это спроектировать свои обновления так, чтобы они не мешали существующему коду, когда приходит время переместить их в другую среду. Это означает, что ваш код должен быть устойчивым к критическим изменениям или просто не выполнять критические изменения до тех пор, пока после весь код не будет обновлен для обработки этих изменений.