Развертывание баз данных SQL Server из Test в Live

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мерф

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