Развертывание баз данных SQL Server от тестирования к жизни

Question

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

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

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

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

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

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

Answer 1

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

В противном случае, я согласен, что redgate стоит дорого, если у вас нет компании, которая покупает его для вас. Если вы можете заставить компанию купить ее для вас, это действительно того стоит!

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

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

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

Answer 10

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

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