Но вопрос интеграции с ветками из других репозиториев. Может удастся придумать что-то

Всем привет, есть вопрос про организацию деплоймента отдельных бранчей в Kubernetes с разным набором env-переменных для каждого бранча - с помощью чего и как вы это делаете?

Когда деплой идёт по тэгам или из одной ветки (master) - тут все просто, можно положить файл .env нужный в репу и менять при необходимости, а секреты создать заранее. А вот когда хочется в разных ветках тестить интеграцию с другими API зависимыми и тоже переключать на версию из бранча - тут встаёт вопрос управления этим добром - как это лучше провернуть? Как вы указываете такие эндпоинты под каждый бранч отдельно?

я из jenkins это делаю. Во время деплоя хожу по всем сервисам на гит, проверяю есть ли там одноименная ветка, если нет, то направляю этот сервис на ветку develop/master этих сервисов.

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

Ну да, это упрощение - делать одноименную ветку, но это не всегда удобно если проекты в Jira разные и тикеты отличаются тоже. Хочется чтобы прям можно было крутить ветки как угодно, соединяя по-разному. Так можно и семвер для сервисов поднять...

ну это получается вручную надо будет прописать все связи? Правильно?

Мне понравилась идея с рандеком - создать выпадающие списки бранчей для сервисов

Тогда можно сделать pipeline в твоей CI, где ты говоришь, куда и что. А он уже запускает задачи с нужными параметрами для каждого сервиса. И получаем. деплой всех сервисов
А про рандек не понял, по описанию это вроде что-то похожее на CI

И потом как-то это скормить все хелму в момент установки

Тогда можно сделать pipeline в твоей CI, где ты говоришь, куда и что. А он уже запускает задачи с нужными параметрами для каждого сервиса. И получаем. деплой всех сервисов
А про рандек не понял, по описанию это вроде что-то похожее на CI

Но вопрос интеграции с ветками из других репозиториев. Может удастся придумать что-то

О да, пока что ничего более логичного кроме shared раннеров per group для preview окружений не придумали

А если в сторону динамических переменных окружения покопать? Вместо статических значений в момент билда получать что-то динамически?

А может попробовать сделать это по гиту, без менюшек. Заходишь в репу, говришь куда какой сервис,  пушишь, а оно тебе деплоет это из нужных веток. Главное чтобы какой-то стандарт деплоя этих сервисов был.
Наверняка тут fluxcd, argocd зайдут на ура

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