Развертывание баз данных SQL Server из тестовой среды в действующую

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

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

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

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

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

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

Ответов (14)

Решение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мерф

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

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

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