Развертывание баз данных SQL Server от тестирования до эксплуатации

08-06-2019
|

Вопрос

Мне интересно, как вы, ребята, управляете развертыванием базы данных между двумя SQL-серверами, в частности SQL Server 2005.Сейчас есть разработка и живая.Поскольку это должно быть частью сценария сборки (стандартный пакет Windows, даже если учесть текущую сложность этих сценариев, я мог бы переключиться на PowerShell или около того позже), Enterprise Manager/Management Studio Express не учитываются.

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

Или, учитывая отсутствие команды «EXPLAIN CREATE TABLE» в T-SQL, вы делаете что-то, что экспортирует существующую базу данных в SQL-скрипты, которые можно запустить на целевом сервере?Если да, существует ли инструмент, который может автоматически выгружать данную базу данных в SQL-запросы и запускается из командной строки?(Опять же, Enterprise Manager/Management Studio Express не в счет).

И, наконец, учитывая тот факт, что действующая база данных уже содержит данные, развертывание может включать не создание всех таблиц, а скорее проверку разницы в структуре и вместо этого ALTER TABLE живых таблиц, что также может потребовать проверки/преобразования данных при изменении существующих полей.

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

Итак, что вы используете для автоматического развертывания баз данных SQL Server от тестирования к работе?

Решение

Я начал вручную кодировать все свои операторы DDL (создание/изменение/удаление), добавляя их в свой .sln в виде текстовых файлов и используя обычное управление версиями (с использованием Subversion, но любой контроль версий должен работать).Таким образом, я не только получаю преимущества от управления версиями, но и обновление в режиме реального времени из dev/stage — это один и тот же процесс для кода и базы данных — теги, ветки и т. д. работают одинаково.

В противном случае я согласен, что Redgate стоит дорого, если у вас нет компании, покупающей его для вас.Однако если вы можете найти компанию, которая купит его для вас, оно того стоит!

Другие советы

В своих проектах я чередую SQL Compare от REd Gate и мастер публикации баз данных от Microsoft, который вы можете скачать бесплатно.здесь.

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

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

Не забудьте решение проблемы от Microsoft: Выпуск базы данных Visual Studio 2008.Включает инструменты для развертывания изменений в базах данных, создания различий между базами данных для изменения схемы и/или данных, модульных тестов, генерации тестовых данных.

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

Как и Роб Аллен, я использую SQL Compare/Data Compare от Redgate.Я также использую мастер публикации базы данных от Microsoft.У меня также есть консольное приложение, которое я написал на C#, которое принимает сценарий sql и запускает его на сервере.Таким образом, вы можете запускать большие сценарии с командами «GO» из командной строки или в пакетном сценарии.

В консольном приложении я использую библиотеки Microsoft.SqlServer.BatchParser.dll и Microsoft.SqlServer.ConnectionInfo.dll.

Я работаю так же, как Карл, сохраняя все свои SQL-скрипты для создания и изменения таблиц в текстовом файле, который хранится в системе контроля версий.Фактически, чтобы избежать проблемы с необходимостью проверки скриптом активной базы данных, чтобы определить, какие ALTER-ы нужно запустить, я обычно работаю следующим образом:

В первой версии я помещаю все во время тестирования в один SQL-скрипт и обрабатываю все таблицы как CREATE.Это означает, что мне приходится часто удалять и читать таблицы во время тестирования, но это не имеет большого значения на ранних этапах проекта (поскольку я все равно обычно взламываю данные, которые использую на этом этапе).
На всех последующих версиях я делаю две вещи:Я создаю новый текстовый файл для хранения SQL-скриптов обновления, содержащих только ALTER для этой версии.И я вношу изменения в оригинал, также создаю новый скрипт базы данных.Таким образом, при обновлении просто запускается сценарий обновления, но если нам нужно воссоздать БД, нам не нужно запускать 100 сценариев, чтобы добиться этого.
В зависимости от того, как я развертываю изменения БД, я также обычно помещаю в БД таблицу версий, содержащую версию БД.Тогда вместо того, чтобы принимать какие-либо человеческие решения о том, какие сценарии запускать, какой бы код, который у меня есть, запускает сценарии создания/обновления, использует версию, чтобы определить, что запускать.

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

Если у вас есть компания, покупающая его, в Toad от Quest Software встроены такие функции управления.По сути, это операция в два клика для сравнения двух схем и создания сценария синхронизации одной с другой.

У них есть версии для большинства популярных баз данных, включая, конечно, Sql Server.

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

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

Используя SMO/DMO, не так уж сложно создать сценарий вашей схемы.Данные немного интереснее, но все же выполнимо.

В общем, я придерживаюсь подхода «Script It», но вы можете рассмотреть что-то в этом роде:

Различайте разработку и стадию, чтобы вы могли разрабатывать с подмножеством данных...Для этого я бы создал инструмент, позволяющий просто извлекать некоторые производственные данные или генерировать фальшивые данные, когда речь идет о безопасности.
Для командной разработки каждое изменение в базе данных должно быть скоординировано между членами вашей команды.Изменения схемы и данных могут осуществляться одновременно, но конкретную функцию должен включать один сценарий.Как только все ваши функции будут готовы, вы объединяете их в один файл SQL и запускаете его для восстановления производства.
Как только ваша промежуточная версия будет одобрена, вы снова запускаете один файл SQL на производственной машине.

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

Я использую механизм миграции Subsonic, поэтому у меня просто есть dll с классами в последовательном порядке и двумя методами: вверх и вниз.В nant имеется привязка сценария непрерывной интеграции/сборки, позволяющая автоматизировать обновление моей базы данных.

Это не лучшая идея в мире, но она лучше, чем написание DDL.

RedGate SqlСравнить на мой взгляд, это путь.Мы регулярно развертываем БД, и с тех пор, как я начал использовать этот инструмент, я никогда не оглядывался назад.Очень интуитивно понятный интерфейс и в итоге экономит много времени.

Версия Pro также позаботится о написании сценариев для интеграции системы управления версиями.

Я также поддерживаю сценарии для всех моих объектов и данных.Для развертывания я написал эту бесплатную утилиту — http://www.sqldart.com.Он позволит вам изменить порядок файлов сценариев и выполнить всю их работу в рамках транзакции.

Я согласен хранить все в системе контроля версий и вручную записывать все изменения.Изменения схемы для одного выпуска вносятся в файл сценария, созданный специально для этого выпуска.Все сохраненные процедуры, представления и т. д. должны помещаться в отдельные файлы и обрабатываться так же, как .cs или .aspx, с точки зрения контроля версий.Я использую сценарий PowerShell для создания одного большого файла .sql для обновления возможностей программирования.

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

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

И у вас обязательно должно быть больше двух баз данных — dev и live.У вас должна быть база данных разработчиков, которую все используют для ежедневных задач разработки.Затем промежуточную базу данных, которая имитирует рабочую среду и используется для проведения интеграционного тестирования.Затем, возможно, полная недавняя производственная копия (восстановленная из полной резервной копии), если это возможно, чтобы ваш последний раунд тестирования установки был сопоставлен с чем-то, что максимально приближено к реальному.

Я создаю всю свою базу данных как DDL, а затем помещаю этот DDL в класс обслуживания схемы.Я могу делать разные вещи для создания DDL, но по сути я выполняю всю поддержку схемы в коде.Это также означает, что если вам нужно делать что-то, не связанное с DDL, и которое плохо отображается в SQL, вы можете написать процедурную логику и запускать ее между фрагментами DDL/DML.

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

БД существует?Если нет, создайте его.
Является ли БД текущей версией?Если нет, то последовательно запустите методы, которые обновляют схему (возможно, вы захотите предложить пользователю подтвердить и - в идеале - сделать резервную копию на этом этапе).

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

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

При разработке в командной среде возникают некоторые проблемы, но в любом случае это более или менее данность!

Мерф

Сейчас я работаю над тем же, что и вы.Не только развертывание баз данных SQL Server от тестирования до эксплуатации, но также включает в себя весь процесс: Локальный -> Интеграция -> Тестирование -> Производство.Итак, что может облегчить мне жизнь каждый день, так это то, что я делаю Задача NAnt с помощью Red-Gate SQL Compare.Я не работаю в RedGate, но должен сказать, что это хороший выбор.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow