Лучшие практики для управления миграциями, которые обновляют несколько баз данных?

Question

Моя команда оценивает инструменты и процессы для управления миграцией базы данных / рефакторинг базы данных, как описано Martin Fowler, Pramod Sadalage, et. и др. Мы заинтересованы в автоматизированных, воспроизводимых, тестируемых процессах, поэтому нас не интересуют такие методы, как ручной запуск SQL Compare при каждом развертывании. В настоящее время мы используем CruiseControl.NET для непрерывной интеграции.

Наша производственная среда имеет несколько серверов баз данных SQL Server 2000 с репликацией между ними. Таким образом, наши миграции будут вносить изменения в схему как на исходном, так и на целевом сервере баз данных.

Чтобы выполнить такую ​​миграцию с помощью такого инструмента, как dbdeploy, кажется, нам нужно запустить миграцию на один из серверов, и нам нужно будет добавить другие серверы в качестве связанных серверов. Таким образом, один сценарий, работающий на главном сервере, может выполнить DDL для любого из связанных серверов.

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

Answer 1

Visual Studio 2008 (Team Edition, в частности GDR) может обрабатывать автоматическое развертывание схемы на основе определенного файла схемы / метаданных, который можно развернуть на серверах. Это может быть включено в ваш процесс сборки / развертывания. Тем не менее, я думаю, что проблема репликации и изменений схемы все еще существует - нет пакета, который понимает / знает о вашей настройке репликации.

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

Answer 2

Здесь, в Red Gate, у нас теперь есть решение для повторяющихся миграций, которое использует SQL Compare и SQL Source Control. Поэтому командную строку SQL Compare можно использовать для поддержки процесса непрерывной интеграции.

http://www.red -gate.com / ОБЪЯВЛЕНИЯ / viewtopic.php? Т = 14107

В настоящее время это ранняя сборка доступа, поэтому мы стремимся получить как можно больше отзывов.

Answer 3

Вы можете попробовать комбинацию Chinchillin и Wizardby : установить агенты Chinchillin на серверах БД и заставить его выполнять сценарии миграции Wizardby в процессе развертывания.

Эта интеграция в разработке, хотя:)

Answer 4

Я не вижу ничего плохого в этом подходе, однако при его настройке обязательно проверьте, что происходит, когда один из связанных серверов не работает. Вы не хотите откатывать все остальные серверы, если один из них вышел из строя, и вы хотите знать, что изменения не были применены к этому серверу.

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