2012-05-19 2 views
3

я следующий сценарий для моего приложения:Flyway/Liquibase для структуры базы данных и DBUnit для вставки базы данных?

  • -Производство серверов
  • 1 Тест сервер
  • п Разработка Компьютеры

Для миграции базы данных мы используем Hibernate схему обновление для схемы и DBUnit для заполнения всех производственных данных (на всех серверах/компьютерах). Когда обновление схемы завершено, я генерирую новый DTD-файл для новой схемы, поэтому я могу сделать новый импорт XML-файла DBUnit. Приложение обновляет базу данных при запуске с помощью XML-файла (только для разработчиков и тестовых серверов/компьютеров!)

Конечно, этот подход не является оптимальным и хрупким. Поэтому я посмотрел на Liquibase и Flyway. Оба кажутся отличными инструментами, но я не получаю: как мне переносить данные? В моем случае я удаляю данные производственной системы один раз в неделю и добавляю ее в исходный элемент управления приложениями как XML-файл DBUnit, поэтому все разработчики имеют «свежие» данные, а тестовый сервер также имеет текущие данные о производстве.

Проблема, которую я вижу с Liquibase и Flyway, заключается в том, что нет решения, как автоматизировать различия с данными базы данных и автоматически генерировать изменения миграции.

Так что моя идея заключается в следующем со следующими шагами:

  1. Набор Hibernate для проверки вместо обновления.
  2. Когда требуется изменение базы данных STRUCTURAL, я добавляю ее в сценарий миграции для основной версии.
  3. В сценарии миграции никаких вставок базы данных нет.
  4. Создайте новый DTD для DBunit на основе новой структуры базы данных
  5. Создайте DBUnit XML из производственной базы данных.

Другой идеей было бы использовать пролетные пути JavaMigration и предоставить исходный дамп базы данных на основе DBUnit. Все другие изменения для данных базы данных будут обрабатываться в сценариях миграции. Но все еще есть проблема: как сделать diff от текущего состояния сценария миграции и состояния базы данных производства?

Было бы удивительным, если кто-нибудь может дать мне намеки, как обрабатывать мой сценарий :)

ответ

1

Если ваша цель состоит в том, чтобы использовать дампы базы данных PROD в DEV и тестирования, я бы:

  • Настройка инструмент миграции БД для запуска при запуске приложения (как пролетный путь и LiquiBase поддерживают это через их соответствующие API)
  • пакета все DB структуры миграции вместе с приложением
  • самосвалы данные и структуру из PROD

Таким образом, когда ПРОД datab ase восстанавливается в DEV или TEST, также восстанавливается старая таблица метаданных инструмента миграции.

Когда приложение запустится, средство миграции обнаружит, что структура db устарела и обновит ее до самой новой версии. Готово.

Не нужно использовать DBUnit для этого.

+0

Я не уверен, как создавать сценарии переноса данных с этим подходом ... Не могли бы вы это прояснить? Есть ли способ с Flyway создать сценарий diff-migration? –

+0

Как я понял, вы делаете все свалку PROD еженедельно. Почему вам также нужен diff данных, если вы все равно даете? –

+0

Я хотел бы создать сценарий миграции со всеми НОВЫМИ данными в производственной базе данных (также с измененными данными). Таким образом, каждую неделю скрипт добавляет новый сценарий перехода на лету в проект (и контроль версий) со всеми различиями в базе данных. Насколько я понял, это рекомендуемый способ (?). Размер моей базы данных составляет несколько сотен мегабайт. Таким образом, каждый полный дамп проверяется на управление версиями (когда это не требуется, так как есть всего несколько наборов данных) будет излишним. –

1

Короткий ответ, что все ваши изменения будут осуществляться через LiquiBase или Flyway.

Мы используем Flyway с той же установкой prod/test/development. Мы делаем все изменения db (структура или метаданные) с использованием сценариев миграции Flyway, хранящихся в исходном управлении. Каждый раз, когда мы делаем новое развертывание в среде, мы сначала запускаем сценарии миграции (используя либо инструмент командной строки, либо плагин maven). Сначала код переходит в среду разработки, тестируется интеграция и продолжает тестироваться и производить.

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

Смежные вопросы