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

хранить в гите кто и когда запустил каждую сборку на свете? Не кажется, что какой-то оверхед?

> Ну вот же))))
Руками - почти тоже самое что и chatopts.

Мой посыл в том, что gitlab ci не покрывает некоторую часть кейсов от которых особо нет смысла избавляться используя gitops, при этом запихивать всё подряд в gitops тоже такая себе работа. Работа ради работы которая не несёт в себе большого смыла.

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

Ну оверхед и ладно, килобайт в Гите и хранение логов исполнения ещё опционально
Роботы ничего не забывают, и поэтому победят нас ж

Вот, например, с БД кейс. Клонируется она для чего? Чтобы тестовое окружение какое-то погонять, вестимо. Можно вполне деплоить гитлабом эти самые окружения. Создал новую ветку, поменял адреса в ансибловом инвентаре. Коммит, пуш, подождал минутку, готово

или чтобы данные обновить продовыми

когда это вдруг понадобилось

Было бы вообще интересно на все это сверху посмотреть, глазами человека с опытом управления командами и внедрения разных cicd & operations паттернов и инструментов
Насколько сложно делать идеальный IAC, хранить все в Гите, какому проценту проектов это подходит, насколько проще командам жить, если можно чтото руками сделать

Это как security
Есть условия и процессы, когда вообще все покрывается проверками на безопасность
И многие без этого вполне себе живут
А IAC из той же оперы, имхо
И кому вот он обязателен, а кому нет?

Но мы это кнчно же не забудем, троллить тебя ещё будем))))

Ну тут такое. Например, отпочковали ветку с большой фичей F, пока ее пилили, в прод уже налили с пяток новых, каждая из которых притащила миграции и БД уже не очень совместима с той, что поднята для F. Обновлять F продовыми данными в таком случае явно не стоит. При таких процессах единственно возможным выглядит накатывание слепка прода на момент разворачивания тестового окружения. А если БД так часто не меняется, можно для тестовых окружений вообще добавить по крону синхронизацию с продом раз в день. И ручных потыкиваний это более не будет требовать

У меня подход такой: однотипные ручные действия никогда не должны становиться повторяющимися. Абсолютно все, что требует повторения может(и должно) быть автоматизировано. Пока мне не довелось работать в таком месте, где такой подход не будет работать..

А что тут меня троллить? Нужно скопировать БД, не ночью, ни сегодня, ни завтра, ни вчера. А тогда, когда нужно. Автоматизируйте на здоровье :)

Да, можно зайти в гит, закоммитить "я Вася, я обновляю базу" и база поехала.
А можно нажать кнопочку в чате и база поехала.
Да, можно нажать кнопочку в чате, которая закоммититла "я Вася, я обновляю базу", но зачем? Какое-то навязчивое желание запихнуть всё в IaC/gitops.

Эм, и зачем тут коммит? Кнопочка просто дёргает пайплайн

Да, так норм. Но в гитлабе с этим не так всё просто :)

А что там с этим непросто?

Это либо много реп на каждый вид задач, либо одна большая репа, в которой 1 пайплайн, который делает 100500 вещей.

Не 100500 вещей