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

Question

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

Murph

Answer 4

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

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

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

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