Развертывание баз данных сервера SQL из теста в жизнь

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мерф

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