И? Если сдохнут то что?

мы мигрировали с 11ой на 12 недели 3 назад. Переписывали кучу несовместимости! так что закладывайте время на обратную совместимость

у меня довольно простая инфраструктура, почти ничего не пришлось менять, кроме новых оборотов hcl 12 ой версии

Убить окружение

отличное решение для продакшен среды

Вопрос же про дев стенды

Читай внимательно

Все дев стенды потом внезапно становятся ЮАТ и попадают в прод....

У меня перестали работать remote exec :)

Какие-то проблемы были с директивой public_ip_address

- не знаком с термином юат
- возможно мы по разному(терминологически) понимаем дев окружение, для меня дев стенды - среда где деплоится фича ветка к примеру, что тестирования

UAT
Если уж рассмытривать дев, то его схема/архитектура должна быть близкой к UAT,SIT,PROD могут разлечаться некоторые параметры, ибо какой от него толк если он далек от того что хотим полчить в итоге?

:)

Я скорее о том, что отпечаток на понимание накладывает текущий продукт, что это? Коробка? вебсервис? мобильное приложение?

какая разница, подходы одни и теже при разработки архитектуры

Есть определенные практики и соблюдать или нет  up to you

👌🏽кто-то хочет поспорить, а не понять мысль собеседника и донести свою

с вами никто и не спорил 😊 ибо не вижу смысла

речь не совсем о том. Проще, наверное, с самого начала :)

есть определённый монолит в процессе распиливания на микросервисы. Для этого монолита надо пока что время от времени и впоследствии на каждый коммит поднимать тестовый стенд, на котором гонять интеграционные тесты.

как сделано сейчас - есть репа terraform с пайплайном, который при помощи нескольких переменных поднимает тестовый стенд, регистрирует его в DNS итд итп. По факту информация о том, что стенд поднят хранится только в рамках гитлаба (несмотря на то, что стейт хранится на S3) и в виде того, что "такой-то пайплайн отработал и находится в состоянии "ожидает destroy"", destroy, соотв, запускается ручками (когда стенд уже не нужен).

разработчики просят большей гибкости и большего удобства в параметризации пайплайна, чем запуск его ручками с определёнными переменными. В идеале - какой-нибудь yaml, который потом генерирует нужные сервисы, подключает нужные модули, запускает нужные роли ansible.

вопрос - как было бы правильнее всего организовать а) запуск пайплайнов и б) хранение информации о том, что у нас запущено и как.

конечно, можно было бы сделать репу с каталогом с ямликами, ямлик есть - стенд поднят, триггером выступает коммит. Ямлик удаляется - стенд сносится. Но, говорят, что это не очень удобно.

в общем такой архитектурный вопрос не в стиле "как сделать", а скорее "как правильнее сделать"

стоит ли вообще развёртывание и эксплуатацию встраивать в git flow?