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

Question

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

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

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

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

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

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

Answer 9

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

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

Answer 10

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

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

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

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

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

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

Murph

Answer 11

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

Его не самый лучший из всех в мире, но он превосходит написание DDL.

Answer 12

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

В версии Pro также учтены сценарии интеграции интеграции с источником.

Answer 13

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

Answer 14

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