Просто в инфре могут быть связанные вещи, которые могут изменятья по отдельности, при этом конфликта в коде не будет, он будет только во время применения конфигурации

Ага. Один пилит одну фичу (бекенд деплой) а другой - другую (фронтенд деплой)

Нужно чтобы они вошли в инфраструктуру как один мерж

А на стадии разработки - пофиг

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

Как пересоздался?

А. Ну с ТФ видимо да. С CF все повторяемо

Ну косякнул кто-то, смержил свой pr по vpc, а, тот кто балансеры делал даже не увидит, что у него все сломается

Если бы он ручками запускал apply, то увидел бы и остановился. Например, vpc не пересоздался, а создался новый и обновил outputs

Второй увидит что код отстал ведь

Так конфликта не будет, мердж сработает

А

Да. Надо дополнительно тестить ещё

Нетривиальное решение. Нужны люди и время

Имхо для малого количества контролировать мержи норм

Пускай тестят локально, потом делать ревью

Локально - на своих акках итд

Linux должен быть бесплатным, а вот за знания про него нужно платить!
Примерно так работает тот самый решающий рыночек, но конкретно сейчас на дворе аттракцион невиданной щедрости: можно скачать 6 книг по линуксам, питону и скриптингу безвозмездно т.е. даром.
Актуально до субботы, так что беги скачивать.
P.S. Правда книги эти в kindle формате.
P.P.S. Правда читалки лучше kindle всё ещё не придумало, так что не вижу проблемы.
https://courses.linuxtrainingacademy.com/kindle-books/

Привет  всему  сообществу  воюю с  поднятием  на локальной  машине кластера кубернетес и  хелма после  сделаных всех нужных телодвижений ложлю вот  такую ошибку!!!!!
helm version
Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}

или  вот ето
kubectl -n kube-system port-forward pod/tiller-deploy-64445f4d64-xzbv6 :44134
error: error upgrading connection: unable to upgrade connection: pod does not exist