Пересматривал доклад по werf и вот такой вопрос. Gitops и

immutable infrastructure идут рука об руку, one image to rule them all, всё хорошо. НО. Но как быть, если приложению на стадии сборки нужно дать информацию о том, где оно будет работать, например, ssr фреймворки, тот же next. То бишь мы не можем один собрать образ, его отдать на тест, его же запустить на preview, и его потом кинуть в прод. Ибо env переменные у окружений разные и разные образы.
Выше у меня как раз были проблемы из-за этого (вынуть из values.yaml переменные на основе werf.env для сборки). И это больше теоретический вопрос к опытным разработчикам. Получается подобные приложения никак не вписываются в immutable инфраструктуру. И у нас будут отдельные образы для preview, staging, prod.
Есть ли какие-то мысли по этому поводу?

По моему опыту все фронты/фреймворки просто параметризуются в рантайме. Вот канонический пример с картинками: immutablewebapps(dot)com А в конкретном случае надо гуглить: "${framework_name} runtime environment variables"

Если у вас содержимое контейнера полу-динамическое, то и тестирование будет полу-динамическим. Т.е. вы уже не код тестируете, а код+контент. Соответственно - либо несёте риски на продакшен (если они не велики), либо строите разветвитель пайплайнов (по количеству окружений) 🤷🏼‍♂️

Ну вот я в эту сторону и предполагал, что риски оценить от одной переменной может и не большие быть (если при билде неверно сгенерировалась страница, то максимум клиент увидит неоплноценный статичный html, с отсутствующим куском кода. А если есть ревалидаций (ISR подход), то она позже и обновится в нормальное состояние). Либо как раз полноценные ветви билд-тест-деплой делать отдельно для каждого окружения. И если планировать полностью избежать рисков - остается лишь второй вариант. А в целом, по вашему опыту, это корректно\нормально получается? полноценный пайплайн для каждого контура