@yamlcoder
Вопрос свелся к тому что, сохранять ли инфу о совместимости версий репы кодовой с инфра репой. Если сохранять, то ифра репу можно хранить как сабмодуль или в прям в кодовой репе. Если нет, то я пока не понял, как решать свои проблемы, свзяанные с этим.

В кластер. Ты напоминаешь 23-летнего сеньёра из Э42. Ты не всю инфру обновляешь везде и сразу. А по canary/rolling/blue-green

Начнёшь хранить стейты инфры в базе и вернёшься в мир заббикса и винды

Для этого автосквош есть :) Но кодеры вообще тут не при чём. У вас должно быть две репы, для инфраструктуры и для кода, отдельно

1) Кодер херачит код в мастер
2) Ставит новый тег
3) Идёт и выставляет в репе инфры новый тег
4) Коммитит
5) CI запускает деплой
6) Если во время деплоя возникают проблемы, то загорается alert
7) Дежурный разработчик лезет смотреть что сломалось
8) По завершении дебага делает реверт в гите инфраструктуры

> Всё так. в инфра репу рендерятся готовые к деплою манифесты.
Ну окей начнем заново.


Смотри. У тебя есть инфра репа, есть репа с кодом сервиса.

v1.0.1 код сервиса требует два деплоймента и cronjob
v1.0.2 код сервиса требует только один деплоймент


Нужно откатить с v1.0.2 до v1.0.1. Если мы просто пропишем v1.0.1 и запушим, приложение сломается, так как оно зависело от двух деплойментов и cronjob. А они пропали

@elemir90 Как я понял предлагает, чтобы master инфра репы, всегда соотвесвтовал состоянию в кубе + никаких автоматических откатов.

То есть для отката, нужно найти коммит в инфра репе, когда в нем был проиписан сервис версии v1.0.1 и сделать revert до этого коммита. И запушить.

Сейчас я делаю по другому. У меня либо инфра репа  это сабмодуль в репе сервиса, либо описание ифнры просто лежит вместе с сервисом. И для отката, нужно просто выбрать нужную версию сервиса и задеплоить, и это гарантировано дает описание инфры совместимое с нужной версией сервиса.

И я не понимаю в чем приемущество его описанного подхода. Вот и все. Пытаюсь выяснить

@yamlcoder
Вопрос свелся к тому что, сохранять ли инфу о совместимости версий репы кодовой с инфра репой. Если сохранять, то ифра репу можно хранить как сабмодуль или в прям в кодовой репе. Если нет, то я пока не понял, как решать свои проблемы, свзяанные с этим.

Никаких сабмодулей, толко номера версий (теги) в пайплайн

> То есть для отката, нужно найти коммит в инфра репе, когда в нем был проиписан сервис версии v1.0.1 и сделать revert до этого коммита. И запушить.

Не совсем. для отката надо найти коммит v1.0.2 и заревертить его. т.е. в общем случае мы не откаывается к чему-то, а отменяем что-то.

> И я не понимаю в чем приемущество его подхода.

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

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

Так же инфра репа сериализует все изменения: пока одно изменения инфра репы выкатывается, другие ждут.  это позволяет избежать некоторых ошибок.

Поэтому всё должно быть обмазано тестами и должны быть известны/указаны совместимые версии. Requirements.txt

Это идеальный мир

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

> Не совсем. для отката надо найти коммит v1.0.2 и заревертить его. т.е. в общем случае мы не откаывается к чему-то, а отменяем что-то.

нет.
Если например ты откатываешь с v1.0.3 до v1.0.1 разреверт тебя откатит на v1.0.2

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

Да, это приемущество. Удобно отдельно  и выкатывать, я не спорю. Я говорю о минусах. Как в примере выше, когда у тебя конкретная версия приложения, зависит от конкретной версии описания инфраструктуры. Либо тебе нужно хранить зависимость версии приложения от версии описания инфраструктуры через сабмодули,  что противоречит подходу предложенному @elemir90 Евгением.


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

Ну эту проблему я и решаю, храня CI скрипты и описание инфры либо как сабмодули либо вместе с кодом сервиса.
Откат на тег полугодичной давно = использования CI скриптов и описания инфры полугодичной давности.


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

Ну я вот и спрашиваю, как принято решать проблемы. Когда у тебя одна версия приложения зависит от определенной версии тупой как пробки репы. Я ее решаю через сабмодули или сохраняя вместе с кодом сервиса