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

Question

[Sergey Filnor]

Доброй ночи!

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

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

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

Визуализация:


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

Comments

[Дмитрий]

cherry pick не поможет?

[Sergey Filnor]

Дмитрий, Честно, первый раз прочитал за эту команду. Попробовал на тестовом проекте, выглядит на самом как неплохое, но временное решение проблемы.

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

Спасибо за наводку с командой

[Дмитрий]

Sergey Filnor, по сути вам надо два репа на фронт, а бэк общий

[Sergey Filnor]

Дмитрий, Это сложновато сделать в условиях того что проект монолитный, а разница в под-проектах не только во фронте, но и в беке.
Если бы бек был идентичный, то проблем бы не было :(

В любом случае, за cherry-pick, спасибо, проверил сегодня уже на рабочем проекте - это действительно временное решение. Буду дальше думать над архитектурой, как это можно будет сделать правильней.

Если оформите отдельным ответом, отмечу решением.

Answer 1

[Василий Банников]

Не бывает такого, чтобы было несколько продов с разными фичами.
Если у вас есть - значит вы называете вещи не теми словами.
Разберитесь, в каком порядке и по какому принципу фичи на эти ветки заливаются.

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

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

UPD:
Посмотрел на иллюстрацию и увидел фразу "Production divided into two instances"
Гит не должен знать, сколько у вас экземпляров сервиса.
Что вы будете делать, если у вас в какой-то момент станет 100 экземпляров, которые динамически могут масштабироваться вплоть до 500 и обратно?

Comments

[Sergey Filnor]

Тут возможно я не совсем правильно назвал это на схеме.
То что я обозначил как два экземпляра - это не совсем так. Это отдельная версия проекта, которая имеет свою логику + какую-то часть логики которую проект унаследовал со своего оригинала и которая все еще продолжает обновляться.
Их не будет больше 2, по крайней мере в ближайшей перспективе.

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

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

[Василий Банников]

Sergey Filnor, ну тогда остаётся cherry-pick

[Sergey Filnor]

Василий Банников, Сегодня проверил cherry-pick на небольшой фиче - это действительно временное решение, которое упростит работу.
А дальше нужно думать о том, как организовать архитектуру проекта, чтобы это все более удобно релизить.
Спасибо за ответ

Answer 2

[Saboteur]

Варианта два.
1. Переразбить каталоги в репозитории таким образом, чтобы общие вещи было /common, разные вещи были в /prod1 /prod2 и при сборке соответсвенно собирать разные дистрибутивы из (common+prod1) или (common+prod), каждый со своим набором фич. Для этого и джобы в CI разные сделать. Можно даже девелоперов в разные команды распределить. Зависит от того, насколько далеко будут расползаться ваши продукты

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

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