Каков простой способ развертывания изменений базы данных с помощью SQL Server?
программная система, над которой я работаю, - это медицинская биллинговая система, большие объемы данных и таблиц данных, а также хранимые процедуры.
Я читал статью"12 шагов к лучшему коду " и в тесте Джоэла #2 говорится: можете ли вы сделать сборку за один шаг?
теперь мне было интересно, означает ли это сборку развертывания (чтобы клиент мог обновить свое развертывание).
теперь основная проблема, с которой я сталкиваюсь, заключается в том, как вы делаете один шаг базы данных обновление?
в текущий момент, когда мы вносим изменения в базу данных, все изменения записываются и добавляются в сценарий обновления базы данных, который получает номер версии, прикрепленный к нему при создании развертывания для сборки клиента.
есть ли простой способ сделать это? Какой-то скрипт или приложение, которое принимает "до и после" посмотрите на схему базы данных и создает сценарий обновления, как я упоминал?
или это просто так, как все это делают, что я трудно поверить, но правдоподобно.
автоматизированная система уменьшит ошибки и значительно ускорит время сборки развертывания, и мне было бы интересно узнать, как это сделать.
7 ответов
есть различные уровни сложности, которые вы можете пройти:
Если у вас есть сценарии обновления, которые вы создаете вручную, и просто ищете способ легко применить их к различным серверам, проверьте ночь в SQL развернуть по SSW Консалтинг. Он может справиться с этим сценарием очень красиво
Если вы склонны делать больше подхода к базе данных diff, то Red Gate's SQL Compare (уже упоминалось) и SQL Packager сделайте отличную комбинацию. Вы можете различать базу данных между старой и новой, а затем применять изменения в хорошем пакете - как EXE или проект C#
Если вы хотите реальный, сквозной, хорошо продуманный подход (с немного кривой обучения), проверьте Innovartis' DBGhost подход. Это целая методология / техника, как обрабатывать разработку базы данных и инкрементные обновления. Он очень мощный и выглядит очень многообещающе - но это немного подход "все или ничего": либо вы покупаете его и используете его от начала до конца, либо вы не
надеюсь, это поможет немного!
посмотреть в этом блоге. Я использовал этот тип одиночного сценария обновления из любой версии БД в нескольких проектах, и он работает довольно хорошо.
http://blogs.msdn.com/danhardan/archive/2007/03/30/database-change-scripts-mambo-style.aspx
возможно, вам придется немного настроить рабочий процесс, чтобы соответствовать вашему рабочему процессу и / или обновить шаблон .sql-файл, но в целом я нашел идею довольно солидного подхода к БД развертывания.
EDIT: просто чтобы уточнить, как я использовал эту технику. В принципе, все мои скрипты ревизии БД помещаются в систему управления версиями. Затем, как шаг post build на поле build, этот инструмент Mambo запускается в каталоге scripts, чтобы свернуть сценарии в один сценарий, охватываемый транзакцией, чтобы разрешить откат, если что-то пойдет не так. Затем, установщик достаточно умен, чтобы искать .сценарий sql для работы с существующей базой данных.
причина это работает, потому что свернутый скрипт проверяет, чтобы увидеть каждый фрагмент, который был отдельным скриптом, уже запущен в нужной базе данных. В результате запускаются только последние сценарии. Предостережение заключается в том, что после регистрации сценария в системе управления версиями и его развертывания его нельзя изменить, так как таблица отслеживания уже считает, что сценарий запущен. Это нормально для проектов, над которыми я работал, потому что мы просто добавляем другой скрипт в папку scripts.
надеюсь Я объясняю процесс достаточно хорошо, чтобы понять. Это действительно не так сложно и может быть очень полезно, если подход применим к вашему проекту.
redgate имеет инструмент SQL Compare для сравнения баз данных и создания сценария для синхронизации. Мы использовали его, но недавно переключились на ручные скрипты, используя тот же процесс, который вы описываете. Использование ручных, мелкозернистых скриптов с уникальным номером версии хорошо сработало.
наши сценарии обновления интегрированы в модульные тесты, поэтому они тестируются вместе с кодом в рамках непрерывной интеграции. Я думаю, что это важная часть " создания постройте в одном шаге."
ответ на первый вопрос: "теперь мне было интересно, означает ли это сборку развертывания (чтобы клиент мог обновить свое развертывание)?"
Я считаю, что Джоэл Тест № 2 не для ходов развертывания на прод, но для continuios интеграции в ходе развития.
Что касается изменений базы данных в prod, все они должны выполняться через скрипт как часть развертывания транзакции или после резервного копирования базы данных. Вы всегда хотите иметь возможность перемещаться назад что-то не получается в развертывании.
разработайте свою базу данных как набор патчей, которые зависят друг от друга. Затем используйте такой инструмент, какhttps://github.com/LuvDaSun/sqlpatch (мной) для создания файла sql для развертывания.
sqlpatch будет сортировать исправления в правильном порядке и убедитесь, что каждый патч выполняется ровно один раз, даже если один и тот же скрипт выполняется дважды.
эта стратегия может использоваться для развертывания базы данных в среде ci / cd. Это делает развертывание таким же простым, как нажатие на ветку.
есть приложения, которые синхронизируют базы данных, но я думаю, что вам лучше делать то, что вы делаете. Написание сценария для обновления базы данных дает возможность обрабатывать ошибки и выполнять транзакции. Это считается наилучшей практикой.
компания Microsoft представила себя приложения уровня данных в SQL 2012 в качестве бесплатной опции для развертывания и обновления баз данных.
Я использую и такой инструмент, в том числе для развертывания производства.