filnor
@filnor
¯\_( ツ)_/¯

Как релизить фичи сразу в две ветки?

Доброй ночи!

Какая история. У нас в проекте используется следующая система веток:
- Production (Релизная версия проекта, с автодеплоем в прод после мержа кода с staging)
- Staging (Тестовое окружение, куда релизяться фичи с автодеплоем на тестовый сервер)
- Feature-ветки (В которых происходит работа).

Собственно, проект прекрасно жил на этой структуре до момента, когда пришлось разделить production версию на две.
Решили использовать одну и ту же бизнес-логику в двух версиях проекта. Бекенд один, но две абсолютно разные вьюшки.

Когда идет работа с фронтом - проблем нету. Свичнулись в нужную ветку, создали с нее feature-branch и дальше по обычному flow. Но когда доходит речь до разработки бекенда, приходится делать фичу, релизить, а потом повторно делать тоже самое для второй версии прода.
Не очень удобно. При этом всем - логика которая пишется, она 100% уникальна и не возникает никаких конфликтов ни с одной из версий прода.

Визуализация:
613a77a65750e184019345.png

Есть ли возможность как-то релизить фичи сразу в две версии прода? Т.е как-то решить задачу на уровне системы контроля версий, а не на уровне архитектуры проекта?
  • Вопрос задан
  • 237 просмотров
Пригласить эксперта
Ответы на вопрос 2
vabka
@vabka
Токсичный шарпист
Не бывает такого, чтобы было несколько продов с разными фичами.
Если у вас есть - значит вы называете вещи не теми словами.
Разберитесь, в каком порядке и по какому принципу фичи на эти ветки заливаются.

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

Но если конкретно по вопросу - в гите нет такой фичи, чтобы мержить одну ветку одновременно в две другие - это придётся делать двумя отдельными операциями (мерж в первую, а потом мерж во вторую).

UPD:
Посмотрел на иллюстрацию и увидел фразу "Production divided into two instances"
Гит не должен знать, сколько у вас экземпляров сервиса.
Что вы будете делать, если у вас в какой-то момент станет 100 экземпляров, которые динамически могут масштабироваться вплоть до 500 и обратно?
Ответ написан
saboteur_kiev
@saboteur_kiev
software engineer
Варианта два.
1. Переразбить каталоги в репозитории таким образом, чтобы общие вещи было /common, разные вещи были в /prod1 /prod2 и при сборке соответсвенно собирать разные дистрибутивы из (common+prod1) или (common+prod), каждый со своим набором фич. Для этого и джобы в CI разные сделать. Можно даже девелоперов в разные команды распределить. Зависит от того, насколько далеко будут расползаться ваши продукты

2. Сделать, чтобы включение фич зависело от конфигов. Тогда дистрибутив будет один, но в конфиге prod1 будет feature1=enabled, feature2=disabled и в prod2 будет наоборот.

Выбирайте что вам подходит больше. Может какая-то смесь.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы