Сравнение между инструментами
Фото Ариан Сингх вкл. Снять защитную пленку
Как разработчик программного обеспечения, я хочу автоматизировать миграцию своих реляционных баз данных в тестовых, промежуточных или производственных средах. Чтобы достичь этого, я протестировал два инструмента миграции, широко известных в Java universe: Ликвидная база и Пролет .
Стек, стоящий за этим тестовым проектом, был:
- Весенняя загрузка и приложение Java 11.
- База данных MySQL.
- Плагин Maven для запуска как Liquibase, так и Flyway.
Некоторая предыстория
Изменения базы данных могут быть болезненными и разрушительными не только для монолитов, но особенно для распределенных систем. Я нашел несколько рекомендаций о лучших практиках, таких как статья “Эволюционный дизайн базы данных” Мартина Фаулера и этот разговор плюс книга Эдсона Янаги.
Грубо говоря, важными вещами являются:
- Сохранить версию скриптов базы данных с кодом приложения.
- Чтобы сохранить обратную и прямую совместимость . Например, столбец таблицы нельзя переименовать сразу. Необходимо иметь промежуточные состояния между этим действием: добавить новый столбец, записать в оба столбца в версии 1.x, изменить код для чтения нового столбца в версии 2.x и удалить столбец в версии 3.x.
Автоматизация задач
Я не хочу, чтобы вся моя команда имела прямой доступ к тестовым, промежуточным или производственным базам данных а также я не хочу выполнять скрипты вручную. Liquibase и Flyway будут играть эту роль, и все, что мне нужно сделать, это написать сценарии.
Поскольку я протестировал бесплатную версию обоих инструментов с базой данных MySQL в проекте Spring Boot и плагине Maven , я кратко изложу их функциональные возможности и почему я выбрал один вместо другого.
Существует множество статей, посвященных Liquibase и Flyway, поэтому я не буду подробно рассказывать о них.
Вы можете просмотреть эти две отдельные истории для краткого обзора:
- вот пролет и
- вот Ликвидная база
И избранный – это…
По моему скромному мнению, оба инструмента великолепны, и они выполняют свою работу. Тем не менее, я решил пойти на Пролет .
Я не верю, что мне когда-нибудь понадобятся все функции, предлагаемые Liquibase, и настраивать и запускать его было немного сложнее, чем Flyway. Кроме того, я всегда находил XML-файлы какими-то грязными/уродливыми. извините
Для XML-файлов необходимо соблюдать шаблон, беспокоиться об обязательном теге База данныхангелог и его версия. У меня возникли некоторые ошибки с файлом журнала изменений, потому что я начал с более старой версии Liquibase. Когда я обновил его, необходимо было изменить версию XML-файлов.
Я знаю, что это не имеет большого значения но нет необходимости делать это с Flyway.
Кроме того, конфигурация ( конфигурация пролета.свойства ) казалась проще и чище, чем Liquibase ( liquibase.свойства ). Возможно, потому, что вариантов не так много, как на Liquibase. На самом деле мне не нужны все функции, которые предлагает Liquibase, поэтому вместо того, чтобы помогать, они просто создавали некоторый шум.
Например, в начале я не был уверен, почему существуют два похожих свойства: Файл журнала изменений и выходной файл журнала изменений . Этой проблемы не существовало с Flyway.
После того, как он “установлен”, единственное, что нужно сделать, это разместить сценарии в настроенной папке, соблюдая последовательность имен файлов миграции. Никаких дополнительных забот.
Flyway выполняет эту работу сразу, и она гораздо более интуитивно понятна, чем Liquibase. Проще просто написать SQL так, как все уже привыкли, и, таким образом, нет кривой обучения.
Flyway – это наиболее “легкое” и безотказное решение для автоматизации миграции баз данных.
Первоначально опубликовано в моих средних историях.
Оригинал: “https://dev.to/danianepg/database-migrations-with-liquibase-and-flyway-eog”