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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

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

Хотя эта интеграция в разработке :)

Answer 4

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

http://www.red-gate.com/MessageBoard/viewtopic.php?t=14107

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