Что простой способ состоит в том, чтобы развернуть изменения базы данных с помощью SQL Server?
Программная система я продолжаю работать, является медицинской системой расчетов, большими объемами данных и таблицами данных и хранимыми процедурами.
Я читал статью "12 Шагов к Лучшему Коду" и в состояниях Joel Test № 2: можно ли сделать сборку за один шаг?
Теперь я задавался вопросом, делает эту среднюю сборку развертывания (так, чтобы клиент мог обновить их развертывание).
Теперь основной вопрос, на который я натыкаюсь, как дела одно обновление базы данных шага?
В текущее время, когда мы вносим изменения в базу данных, все изменения зарегистрированы и добавлены к сценарию обновления базы данных, который присоединил номер версии к ней, когда развертывание на потребительской сборке создается.
Существует ли более простой способ сделать это? Некоторый сценарий или приложение там, которое берет "прежде и после" взгляда на схему базы данных и создает сценарий обновления как, я упомянул?
Или это просто способ, которым все делают это, который я нашел бы трудно для веры, но вероятный.
Автоматизированная система уменьшила бы ошибки и значительно ускорила бы время изготовления развертывания, и я буду интересоваться знанием, как сделать так.
5 ответов
Есть различные уровни сложности, которые вы можете пройти:
если у вас есть скрипты обновления, которые вы создаете вручную, и вы просто ищете способ легко применить их к различным серверам, обратите внимание на SSW SQL Deploy от SSW Consulting. Он может очень хорошо справиться с этим сценарием
, если вы склонны делать больше различий в подходах к базам данных, то Red Gate SQL Compare (уже упоминалось) и SQL Packager делают отличную комбинацию. Вы можете различать базу данных между старой и новой, а затем применить изменения в хорошем пакете - в виде EXE или C# проекта
, если вам нужен реальный, сквозной, хорошо продуманный подход (с немного кривой обучения), посмотрите на Innovartis' DBGhost подход. Это целая методология / техника, как работать с развитием базы данных и инкрементальными обновлениями. Она очень мощная и выглядит очень многообещающе - но это немного похоже на подход "все или ничего": либо вы покупаете ее и используете ее из конца в конец, либо вы не
Надеюсь, это немного поможет!
.Ответ на первый вопрос "Теперь мне интересно, означает ли это сборку развёртывания (чтобы клиент мог обновить своё развёртывание)?"
Я считаю, что Joel Test #2 предназначен не для развёртывания переходов в prod, а для непрерывной интеграции во время разработки.
Что касается изменений в prod, все они должны быть выполнены через скрипт в рамках развертывания транзакций или после резервного копирования базы данных. Вы всегда хотите иметь возможность вернуться назад, если что-то не получится во время развертывания.
redgate имеет инструмент SQL Compare для сравнения баз данных и создания скрипта для синхронизации. Раньше мы использовали его, но недавно перешли на ручные скрипты, используя тот же самый процесс, который вы описали. Использование ручных, мелкозернистых, скриптов с уникальным номером версии хорошо сработало.
Наши скрипты для обновления интегрированы в юнит-тесты, поэтому они тестируются вместе с кодом в рамках непрерывной интеграции. Думаю, это важная часть "сборки за один шаг"
.Посмотрите на эту запись в блоге. Я использовал этот тип одиночного скрипта обновления из любой версии БД на паре проектов и он работает довольно неплохо.
http://blogs.msdn.com/danhardan/archive/2007/03/30/database-change-scripts-mambo-style.aspx
Вам, возможно, придется немного подкорректировать рабочий процесс и/или обновить шаблонный .sql файл, но в целом я нашел эту идею довольно солидным подходом к установке БД.
EDIT: Просто чтобы подробно рассказать о том, как я использовал эту технику. В основном, все мои сценарии ревизии БД попадают под контроль исходников. Затем, на этапе после сборки, этот инструмент Mambo запускается в каталоге сценариев для отката сценариев в один сценарий, охватываемый транзакцией, чтобы позволить откат, если что-нибудь пойдет не так. Затем программа установки достаточно умна, чтобы искать .sql скрипт для запуска против существующей базы данных.
Причина, по которой это работает, заключается в том, что свернутый скрипт проверяет каждую часть, которая была отдельным скриптом, уже запущена против нужной базы данных. В результате, запускаются только последние скрипты. Оговорка заключается в том, что после того, как скрипт проверен и развернут, вы не сможете его отредактировать, так как таблица отслеживания уже думает, что скрипт был запущен. Это хорошо для проектов, над которыми я работал, потому что мы просто добавляем еще один скрипт в папку скриптов.
Надеюсь, я объясняю процесс достаточно хорошо, чтобы понять. На самом деле он не настолько сложен и может быть весьма полезен, если подход применим к вашему проекту.
Есть приложения, которые синхронизируют базы данных, но я думаю, что вам лучше делать то, что вы делаете. Написание скрипта для обновления базы данных дает вам возможность обрабатывать ошибки и выполнять транзакции. Это считается лучшей практикой.