исправлено

у меня нет, я больше автоматизатор, а не разраб. гуглить только

но тогда:
1. это не пайплайн
2. у вас разные артефакты для каждого типа окружения
3. зачем?

так вопрос как раз в плоскости автоматизации. Разработчики пилять в рамках выстроенного процесса

не надо сюда разработчиков, там вообще тогда цирк будет

1. мультибранч пайплайн
2. разные
3. затем на данный момент схема приемлема, но не без минусов

флагами сами разработчики и рулят. в своих пайплайнах или в энвфайлах

Мы делали  когда-то, что пакет один для тест-стейдж-прод, при деплое только переменные менялись, так мы иммутабельность сохраняли.  Ну то есть ветка была одна релизная, просто с неё всё лилось сначала в тест, потом если ок - в стейдж, потом в прод. Ну а дев - там каждый пилил своё как хотел. Мне в целом такой подход вполне импонирует, но я раньше это делал в ТС+ октопус, а теперь вот надо с Дженкинсом разобраться.

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

Это ещё один способ, если с рестапи не разобрался? :)

так на дженкинсе можно сделать так-же, и с точки зрения CI/CD как принципов это более правильный подход

быстренько пробежался по https://habr.com/ru/post/464021/ и теперь чуть понятнее стало

git flow, который с отдельной develop и отдельными релизными бранчами разрабатывался на основе опыта разработки линукс ядра, которая фактически разработка on-premise продукта, где одновременно поддерживается несколько релизов с бекпортами и т.д.

у нексуса есть апи?))

для не on-premise разработки он избыточен и добавляет кучу проблем не особо упрощая флоу

Да

Ну выше несколько человек уже его посоветовали )

Привет, ребята кто деплоит приложение в куб через Jenkins с помощью helm, удобно ли и стоит ли?  Или хватит обычного kubectl?

не очень удобно, но можно

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