КОНФИГИ Ч.2 ВЕРСИОНИРОВАНИЕ

Структура конфигов в многом копирует (должна копировать) структуру веток проекта
Т.е. каждая ветка смотрит в свою версию конфигов - в свою google таблицу грубо говоря.

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

Вот случаи, когда "конфиги ломаются" чаще всего становятся несовместимы друг с другом:
🔹 Большая фича, которая сильно изменяет структуру конфигов
Если разраб будет менять одну версию конфигов в своей ветке, рано или поздно его версия станет несовместима с другими ветками
🔹 Конфликт веток разработки
Т.е. в версии кода/конфигов в ветках различаются и разрабатывать новые фичи параллельно с релизом не получается.
🔹 ГД работает над балансом и меняет тип данных

Проблемы с пунктами выше будут только если будет 1 версия конфигов на все ветки, а именно:
🔸 Блокировка работы всей команды до момента синхронизации конфигов и кода в ветке(-ах)
🔸 Потенциальная поломка конфигов в проде

Как решить:
🔹 Каждая версия проекта - своя версия конфигов
🔹 При слиянии веток версия конфигов меняется на актуальную

ВЕРСИОНИРОВАНИЕ

Пример:
1️⃣ Стартуем проект с нуля. Все ветки версия 100 (условно)
2️⃣ Как только происходит feature freeze и проект мержится в stable, создается копия конфигов (версия 200) с которой работает только develop.
3️⃣ Выкатка: rc и master по мере слияния смотрят в 100 версию
4️⃣ После релиза master сливается в develop. Изменения из master конфигов переносятся в develop.
5️⃣ Повторить шаги до следующего релиза

Есть нюанс на пункте 4️⃣:
Может быть ситуация когда версия 100 уже не совместима с версией 200.
Но в 99.9% версия 100 структурно является подмножеством версии 200 и нужно лишь пару полей скопировать из одной таблицы в другую.
На крайний случай master данные имеют приоритет и старая 200ая версия удаляется. Делается копия от master версии 200 и ручками восстанавливаются потерянные данные.

Плюсы:
🔸 Возможность бесшовной выкатки. Версия 100 смотрит в свои конфиги, 200 версия в свои. Это позволяет избежать downtime'а, когда версия 200 уже в сторах, но нужно время для пользователей версии 100 чтобы обновиться.
🔸 Снижение до минимума простоя из-за сломанных конфигов внутри команды

Минусы:
🔹 Больше телодвижений и другой подход к работе в команде и способе выкатки в prod.

Что можно упростить:
🔸 В маленьких командах от веток rc и stable можно отказаться и иметь всего 2 версии конфигов для develop и master
🔸 Можно создавать конфиги новой версии на шаге 4️⃣, а не на шаге 2️⃣. Тогда проблема с шагом 4️⃣ можно забыть

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

И последнее, при работе с кофигами важна коммуникация. Оповещайте свою команду, когда вносите значительные изменения.
Берегите свои нервы и нервы людей с кем работаете ❤️

А как по вашему версионирование конфигов вообще нужно в проекте или это over engineering? 🤔

#проект_в_разработке@UniArchitect