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

Интересно, как вы, ребята, управляете развертыванием базы данных между двумя 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?

2.08.2008 23:30:59
14 ОТВЕТОВ
РЕШЕНИЕ

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

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

19
3.08.2008 00:58:16
+1 Я делаю изменения с помощью графического интерфейса пользователя в SSMS (или Enterprise Manager в SQL2000), но использую значок «Создать сценарий изменения» для создания сценария, который я сохраняю для создания сценария изменения для следующего выпуска. Есть флажок «Автоматически вносить изменения в скрипт», на случай, если вы забудете один день!
Kristen 18.02.2009 10:42:56

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

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

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

13
2.08.2008 23:40:04

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

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

7
18.02.2009 09:08:08

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

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

5
27.08.2008 01:10:12

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

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

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

3
3.08.2008 00:37:03

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

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

2
3.08.2008 00:22:03

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

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

2
3.08.2008 01:38:02

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

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

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

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

2
4.08.2008 17:38:59

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

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

2
26.08.2008 17:39:20

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

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

2
28.08.2008 00:22:08

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

2
8.06.2010 21:33:36

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

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

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

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

1
13.08.2008 15:41:44

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

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

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

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

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

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

Murph

1
26.08.2008 15:38:22

В настоящее время я работаю над вами. Не только развертывание баз данных SQL Server из тестирования в живую, но также включает весь процесс из Local -> Integration -> Test -> Production. Так что каждый день я могу легко справиться с задачей - я не выполняю задачу с Red-Gate SQL Compare . Я не работаю на RedGate, но должен сказать, что это хороший выбор.

1
27.11.2008 03:15:45
Ссылка в ответе мертва.
Pang 27.04.2017 06:57:31