Что такое простой способ развертывания изменений базы данных с помощью SQL Server?

Question

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

Я читал статью «12 Steps to Better Code» и в тесте Джоэла №2 говорится: вы можете сделать сборку за один шаг?

Теперь мне было интересно, означает ли это развертывание (чтобы клиент мог обновить свое развертывание).

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

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

Есть ли более простой способ сделать это? Какой-то сценарий или приложение там, где требуется «до и после», посмотреть схему базы данных и создать сценарий обновления, как я уже упоминал?

Или это так, как все это делают, что мне трудно поверить, но правдоподобно.

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

Answer 1

Там в различных уровнях сложности, которые вы можете пройти через:

• если у вас есть обновления скриптов, которые вы создаете вручную, а просто ищете способ легко применять те к различным серверам, проверить SSW SQL Deploy от SSW Consulting. Он может отлично справиться с этим сценарием

• Если вы склонны делать больше подхода к базе данных, то Red Gate's SQL Compare (уже упоминалось) и SQL Packager сделать отличную комбо. Вы можете разделить базу данных между старым и новым, а затем применить изменения в хорошем пакете - в качестве проекта EXE или C#

• , если вы хотите создать реальный, сквозной, продуманный подход (с бит кривой обучения), ознакомьтесь с подходом Innovartis' DBGhost. Это целая методология/методика, как обрабатывать базу данных и инкрементные обновления. Это очень мощное и выглядит очень многообещающе - но это немного из всего или ничего подхода: либо вы покупаете в нее, и использовать его из конца в конец, или вы не

Надеются, что это помогает немного!

Answer 2

Взгляните на это сообщение в блоге. Я использовал этот тип одного сценария обновления из любой версии БД на пару проектов, и он работает очень красиво.

http://blogs.msdn.com/danhardan/archive/2007/03/30/database-change-scripts-mambo-style.aspx

Вы, возможно, придется настроить рабочий процесс немного, чтобы соответствовать ваш рабочий процесс и/или обновления файла .sql шаблона, но в целом я нашел идею быть довольно твердый подход к развертыванию БД.

EDIT: Просто уточните, как я использовал эту технику. В принципе, все мои скрипты ревизии БД попадают в исходный контроль. Затем, в качестве этапа пост-сборки в окне сборки, этот инструмент Mambo запускается в каталоге скриптов, чтобы свернуть скрипты в один сценарий, охватываемый транзакцией, чтобы разрешить откат, если что-то пойдет не так. Затем установщик достаточно умен, чтобы искать сценарий .sql для работы с существующей базой данных.

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

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

Answer 3

Ответ на первый вопрос «Теперь мне было интересно, означает ли это развертывание (чтобы клиент мог обновить свое развертывание)?»

Я считаю, что тест Джоэла № 2 не предназначен для развертывания, чтобы продвигать его, но для интеграции континентов во время разработки.

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

Answer 4

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

Answer 5

redgate имеет инструмент SQL Compare для сравнения баз данных и генерации сценария для синхронизации. Мы использовали его, но в последнее время переключились на ручные скрипты, используя тот же процесс, который вы описываете. Использование ручного, мелкозернистого, сценариев с уникальным номером версии получилось хорошо.

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

Answer 6

Разработайте свою базу данных как набор исправлений, которые зависят от eachother. Затем используйте инструмент, например, https://github.com/LuvDaSun/sqlpatch (по мне), чтобы создать файл sql для развертывания.

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

Эта стратегия может использоваться для развертывания вашей базы данных в среде ci/cd. Это делает развертывание так же просто, как нажатие на ветку.

Answer 7

Microsoft самостоятельно представила Data-tier applications в SQL 2012 как бесплатный вариант для развертывания и обновления баз данных.

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