2013-06-06 5 views
0

В настоящее время наша компания обрабатывает все изменения схемы базы данных, вручную создавая, распространяя и запуская необходимые SQL-скрипты. Очевидно, что это приводит к проблемам, поскольку различные машины обновляются спорадически и редко.Управление миграцией на пролетной линии

Я изучаю более современные подходы к обработке этого, и Flyway является ведущим кандидатом прямо сейчас (хотя мы все еще открыты для использования Liquibase, если для этого можно сделать убедительный аргумент).

Обычный поток достаточно прост и работает так же просто, как и рекламируется, но мы не знаем, как правильно адресовать конфликтующие сценарии миграции. Например, 2 разработчика в разных личных филиалах (A и B) добавили один столбец в таблицу в разных миграциях (MigrationA и MigrationB). Dev на ветке B понимает, что MigrationB не требуется после того, как он уже запустил его в своей базе данных. К сожалению, на данный момент повреждение сделано, и запись была записана в таблицу schema_version в базе данных B. Поскольку Flyway не поддерживает откаты, каков соответствующий ответ в такой ситуации?

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

Благодарим за любые ответы, связанные с конкретными данными, или более общие объяснения/примеры того, как люди успешно перешли на пролет.

+0

Хотя я поддерживаю подход «чистого слайда» для dev/Q, слово предупреждения из опыта: не забудьте проверить миграции из нечистых состояний и как система реагирует, если она получает нормальную нагрузку. Devs имеют тенденцию просто создавать несколько тестовых записей, и поэтому некоторые ошибки проскальзывают под их радаром. – Zefiro

ответ

0

Вы правы.

Базы данных DEV могут и должны рассматриваться как одноразовые, и Flyway поддерживает это отлично. Это позволяет вам воссоздать их детерминистически подмигиванием. Это важно для сценария, описанного выше, и для многих других, таких как создание новых тестовых сред и внедрение новых разработчиков.

+0

Отлично, спасибо за проверку! – Bill

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