вы организуете деплой с необходимостью при этом обновить еще и таблицы в БД? Ну т.е. например в версии 1.2 приложения потребовались в БД еще пара таблиц, без которых оно работать не будет, как это правильно задеплоить? Использовать какой-то init контейнер? А как-то можно задавать, чтобы он не каждый раз запускался, а по какому-то тригеру?
Что-то все равно не понимаю :/ Большинством выиграла джоба, но как она тригерится то, по какому принципу? Вот есть допустим liquibase, он в репозитории с кодом программы, настроено и вот это все. Допустим мы собрали образ с liquibase, указали его в джобе. А как тригерить то эту джобу? Руками что-ли в гитлабе кнопку делать для этого в деплой пайплайне (типа kubectl apply -f job.yaml)? А в автоматическом режиме как? Прехуками в хелме? Но ведь в таком случае эта джоба будет запускаться каждый раз, когда мы будет деплоить новую версию приложения, даже не смотря на то, нужны ли нам изменения в бд... или это ок (ну запустится, само увидит что апдейтов нет и завершится), в этом и смысл фреймворка миграций, чтобы он сам понимал обновляться ему или нет?
"Да" на то, что норм когда джоба запускается при каждом деплое, даже когда миграции не нужны?
кто решает нужны миграции или нет? Состояние в бд или левая пятка одного из кожаных мешков?
Разраб, когда делает новую версию приложения? После чего правит liquibase? Вот здесь и вопрос, нужно ли завязывать деплой на изменения в liquibase и типа если он изменился - катить с джобой, а если не изменился катить без джобы, или это так не должно работать, и смысл liquibase в том, чтобы он сам определял статус БД, а мы просто без задней мысли его запускаем каждый раз и все (и если были в нем правки, он правит БД, если не были, не правит)? Или я вообще не понимаю про что речь?
Не разраб решает, он только код пишет как поменять бд. Нецелесообразно выносить состояние бд и логику сопровождения на этап деплоя, для этого уже есть готовые инструменты один из которых liquibase
Обсуждают сегодня