Деплой ветки в отдельное окружение

Бэк - это типа серверный код. Фронт - это типа клиентский код. Сама архитектура называется клиент-сервер, но за последние 20 лет её сильно исказили, так как и серверный код, и клиентский код выполняется на машине сервера, а часть генерируемого клиентским кодом контента, как ни странно это звучит, «выполняется» на клиентской машине. Так, а что собственно непонятно в этой трёхзвенной схеме?

Если ветки ключевых 3 (условно dev, stage, prod) — тут все понятно. Попарно бэк и фронт деплоятся, ip или dns не меняются.

А теперь добавляем туда ещё тьму фич, которые тестеры хотят тестить отдельно. И фичи эти могут быть во фронте и в беке.

Как теперь спаривать br1 фронта и br1 бэка?

Понятно же что я хочу полный CI, да?

Бест практис?

Но вроде не круто фронт и бек проекта в одной репе хранить?

Почему? Очень даже ничего, это удобно. Если только команда большая, то есть какие то преимущества от отдельных реп.

Я деплою никсом, меняешь конфиг, порты например, и все пучком.

Но вроде не круто фронт и бек проекта в одной репе хранить?

Воткни бэк подмодулем в репу фронта. Или ещё как-то привязку сделай, если у тебя «парные» ветки. Но монорепа проще.

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

Хм, ну кстати.

Пользуешься? Грабли?

Кто выбирает ветки? Как?

Вы как-то очень сильно на своей волне. Непонятно что вы делаете сейчас, а потому и сложно сказать как это можно улучшить.

в интеграционную ветку это всё деплоится, а интеграционная ветка деплоится в тестинг. погугли gitflow.

Можно мержить покрытые автотестами бековые ветки в дев, затем выкатывать ветки фронта по отдельным дев-поддоменам (что дёшево, так как чистая статика), там же тестить руками и/или автотестами, затем мержить фронт в дев. Ну а дальше стейдж и прод.

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

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

сейчас есть две репы: бэк и фронт. там и там есть master, dev и толпа features/feature_id.

процесс как везде: dev –branch-> feature_id –MR-> dev —> CI —> deploy_for_tests.

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

теперь тестеры начинают ныть: «мы хочим тестить ветки отдельно». ну допустим, да, но как же ветка фронта feature_1 узнает IP парного бэка, у которого тоже есть свои feature_n?

процесс как везде:

У каждого свои тараканы.

во вронт он захардкожен

Зря.

но как же ветка фронта feature_1 узнает IP парного бэка, у которого тоже есть свои feature_n?

Как-как? Из файла настроек.

И правильно тестеры ноют. ;) Если разбил ветки, а у тебя прямая зависимость проектов - это или надо в одну собирать или делать нормально, независимо. Криво, короче, у тебя.

И сделай ты файл настроек под тест (кто у тебя там тестовый сервер, тот IP и предлагай в инструкции). И вообще, сделать неплохо для тестеров HowTo

или делать нормально, независимо.

надо делать правильно, а неправильно делать не надо.

отличный совет.

И сделай ты файл настроек под тест (кто у тебя там тестовый сервер, тот IP и предлагай в инструкции).

еще раз: бэков то тоже надо плодить на каждую фичу? т.е. тестовых серверов тоже несколько?

сделать неплохо для тестеров HowTo

что именно туда вписать?

Делаешь чекаут на тесовую ветку и разворачиваешь свой код как обычно, только на тестовом серваке. Тащишь туда настройки для тестовой бд, рабита, монги, кафки и что у тебя там. Всё. А что еще надо? Фронт? Тоже делаешь чекаут и все свои стандартные ритуалы.
А вообще надо сделать вебморду с кнопками «накатить, откатить, похерить, что там по логам, что там по конфигам» а то у меня пачка скриптов для этого и я постоянно забываю что где.

при этом IP бэка один, во вронт он захардкожен

Значит надо разхардкодить. И инстансов сделать не 2 а n.

инстансов сделать не 2 а n.

отличный план, и как теперь направить front_feature_1.my.cool.host на back_feature_2.my.cool.host?

чет мне кажется нифига так никто не делает ))

отличный план, и как теперь направить front_feature_1.my.cool.host на back_feature_2.my.cool.host

Деполем бека с back_feature_2 для front_feature_1. Только не говори теперь, что хочешь беки с разными несовместимыми друг с другом фичами.

чет мне кажется нифига так никто не делает ))

Ну и что? А ты сделай. Пусть все завидуют.

чет мне кажется нифига так никто не делает ))

Ты тёплое с мягким не путай. Если надо по ТЗ что-то делать с back_feature_2.my.cool.host твоему front_feature_1.my.cool.host - делают.

Не делают зависимые связи (не вписывают в код никаких настроек, будь то база данных, адреса и т.д.).

Теперь главный вопрос. Как ты тестировать собрался, если у тебя back вшит? ;)) Должна быть возможность это всё менять по повелению твоей пятки (и без программистов, чтобы развернуть мог сам, что они там понаписывали).

бэков то тоже надо плодить на каждую фичу? т.е. тестовых серверов тоже несколько?

Если нужно тестить back, да на логику… То на те, которые надо тестить - конечно поднимаем, конечно каждый.

Бывало, синтетику проходит, а во время тестирования всплывает такое…

мне почему-то кажется что ты предлагаешь это делать руками.

а я хочу ci: вкомитил, тесты, деплой, радость.

и где на этом этапе надо подсунуть нужный конфиг я нифига не вдупляю.

все завернуть в докер и разворачивать в кубернетесе

нужно больше боли )))

не, ок, не вопрос.

давай, я разраб фронта, ты бека.

я пушнул в репе front_repo ветку feature_0 и feature_1, их можно деплоить и тестить.

ты пушнул в репе back_repo ветки feature_2 и feature_3, их тоже можно деплоить и тестить.

внимание, вопрос: в каком момент и как именно мой фронт поймет где живет твой бэк, чтобы туда слать запросы?

https://semver.org/lang/ru/

короч тут уже нужен ПМ, который будет знать какую версю фронта к какой версии бэка соотнести с нужными фичами, что бы потом деплойнуть это на стейдж и пусть тестировщики тесят. Думаю как-то так норм

С монорепой допустим понятно как.

• и все-же лучше уточнить что под этим понимается

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

Имеет смысл посмотреть в сорону хуков и как вариант через git pull по cron-у, для отдельных фич можно emacs + tramp mode

мне почему-то кажется что ты предлагаешь это делать руками.

Руками - зло.

внимание, вопрос: в каком момент и как именно мой фронт поймет где живет твой бэк, чтобы туда слать запросы?

.env всякие… Там у нас прописано всё, что относится к настройкам приложения (DB, ключики, IP и так далее). Если ты вписал всё это в код, как ты тестируешь? :) На боевом сервере? :))

Если ты заморачивался с API docs - есть всякое Swaggerнутое…

и где на этом этапе надо подсунуть нужный конфиг я нифига не вдупляю.

Жирный ты тролль ;) Или всё так плохо? На чём пишем, если не секрет, front and back?

что ж вы за наркоманы такие…

Если ты вписал всё это в код, как ты тестируешь?

есть .env, там написано back_host=192.168.134.23

ну и чем это не хардкод..?

ты предлагаешь наплодить этих env для каждой фичи? а адрес-то ты как узнаешь…?

Писатель фронта должен знать , для какой версии бека он пишет и где-то указать эту инфу. Версию бека надо проецировать на ИП.

да, но как же ветка фронта feature_1 узнает IP парного бэка, у которого тоже есть свои feature_n?

DNS? Или вот https://www.hashicorp.com/products/consul например.

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

И тут я поперхнулся смузи.

аккуратнее надо.

а то примера конфига от тебя так и не увидим… :(

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

ну не, ветки оставить.