Исправление Aber, (текущая версия) :
Сколько тестовых серверов у вас было? Как отслеживали версии баз на них?
Я поясню что имею ввиду. Можно просто все организовать без liquibase, sql файлы с ченджсетами именованными например датой 20201025.sql, изменения применяются через какой-нибудь cli типа psql для postgres, где обращение к psql спрятано вызовом функции:
apply-sql '1.0/20201024.sql'
все это запускается через самописный apply-db.sh в 100-200 строк. В эти 200 строк уместится вставка мета инфы о перемененных файлах. Все абсолютно прозрачно.
Я не понял что нового привнес liquibase, ну ок, не зависит от ОС, можно на винде использовать и… все.
Отвечая на твои вопросы, там где это было и работало, были две тестовых базы, test, preprod, плюс базы на машинах разработчиков.
Я просто сейчас работаю на проекте с liquibase, и я понимаю что он вообще мне не пригодится. Никогда эту штуку в свой проект я не возьму, она ничем не помогает.
В ряде проектов для тестов используется h2 база и мне это не нравится, т.к. там база не полная, сложные вещи требуют raw-sql и такие ченджсеты не применяются к h2. Плюс ты должен помнить что где-то тут есть raw-sql и его нельзя протестировать против h2 базы, и с этой успокаивающей инфой закоммитить как есть и пойти лечь спасть.
Исправление Aber, :
Сколько тестовых серверов у вас было? Как отслеживали версии баз на них?
Я поясню что имею ввиду. Можно просто все организовать без liquibase, sql файлы с ченджсетами именованными например датой 20201025.sql, изменения применяются через какой-нибудь cli типа psql для postgres, где обращение к psql спрятано вызовом функции:
apply-sql '1.0/20201024.sql'
все это запускается через самописный apply-db.sh в 100-200 строк. В эти 200 строк уместится вставка мета инфы о перемененных файлах. Все абсолютно прозрачно.
Я не понял что нового привнес liquibase, ну ок, не зависит от ОС, можно на винде использовать и… все.
Отвечая на твои вопросы, там где это было и работало, были две тестовых базы, test, preprod, плюс базы на машинах разработчиков.
Я просто сейчас работаю на проекте с liquibase, и я понимаю что он вообще мне не пригодится. Никогда эту штуку в свой проект я не возьму, она ничем не помогает.
В ряде проектов для тестов используется h2 база и мне это не нравится, т.к. там база не полная, сложные вещи требуют raw-sql и такие ченджсеты не применяются к h2. Плюс ты должен помнить что где-то тут есть raw-sql и его нельзя протестировать против h2 базы, и с этой успокаивающей инфой закомитеть как есть и пойти лечь спасть.
Исходная версия Aber, :
Сколько тестовых серверов у вас было? Как отслеживали версии баз на них?
Я поясню что имею ввиду. Можно просто все организовать без liquibase, sql файлы с ченджсетами именованными например датой 20201025.sql, изменения применяются через какой-нибудь cli типа psql для postgres, где обращение к psql спрятано вызовом функции:
apply-sql '1.0/20201024.sql'
все это запускается через самописный apply-db.sh в 100-200 строк. В эти 200 строк уместится вставка мета инфы о перемененных файлах. Все абсолютно прозрачно.
Я не понял что нового привнес liquibase, ну ок, не зависит от ОС, можно на винде использовать и… все.
Отвечая на твои вопросы, там где это было и работало, были две тестовых базы, test, preprod, плюс базы на машинах разработчиков.
Я просто сейчас работаю на проекте с liquibase, и я понимаю что он вообще мне не пригодится. Никогда эту штуку в свой проект я не возьму, она ничем не помогает.
В ряде проектов для тестов используется h2 база и мне это не нравится, т.к. там база не полная, сложные вещи требуют raw-sql и такие ченджсеты не применяются к h2. Плюс ты должен понимать слой работы с базой в котором в котором есть raw-sql против h2 нельзя протестировать.