Нетривиальное инкрементное развертывание изменений с проектами баз данных Visual Studio - PullRequest
Новая
       14

Нетривиальное инкрементное развертывание изменений с проектами баз данных Visual Studio

5 голосов
/ 19 ноября 2009

Давайте предположим, что я делаю какое-то нетривиальное изменение в моей базе данных, которое требует "нестандартной" работы для обновления с версии A на B. Например, преобразование столбцов идентификаторов пользователей из типа данных UUID в имя пользователя домена Windows.

Как я могу сделать это автоматически развертываемым? То есть я хочу позволить разработчикам щелкнуть правой кнопкой мыши проект, выбрать «Развернуть» и выполнить эту логику, если они используют базу данных достаточно старую.

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

Первым логическим препятствием, конечно, будет то, что утилита развертывания не будет знать, нужно ли обновлять какую-либо такую ​​логику - я бы предположил, что мог бы также предоставить логику для этого (например, проверить таблицу версий и если последняя версия <5.0, выполните это обновление, позже добавив строку новой версии). </p>

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

Ответы [ 2 ]

1 голос
/ 15 октября 2013

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

    <RegisterDataTierApplication>True</RegisterDataTierApplication>

Эта опция зарегистрирует схему и ее номер версии в базе данных msdb во время развертывания. Обязательно меняйте номер версии dacpac между выпусками! Мы используем msbuild для создания dacpacs, пример кода для установки версии dacpac: 

DacVersion=$(ProjectReleaseNumber).$(ProjectBuildNumber).$(ProjectRevisionNumber)

Сделав это, вы можете создавать сценарии предварительной установки с учетом версии. 

-- Get installed version, e.g. 2.3.12309.0
DECLARE @InstalledVersion NVARCHAR(64) = (
    SELECT type_version
    FROM msdb.dbo.sysdac_instances
    WHERE instance_name = DB_NAME()
);
-- Get the major part of the version number, e.g. 2
DECLARE @InstalledVersionMajor TINYINT = CONVERT(TINYINT, SUBSTRING(@InstalledVersion, 0, PATINDEX('%.%', @InstalledVersion)));

IF (@InstalledVersionMajor < 5)
BEGIN;
    PRINT 'Do some nontrivial incremental change that only needs to be applied on version before 5';
END;

Проверка номера версии, которую вы сейчас внедряете, немного сложнее, но ее также можно сделать. Посмотрите превосходный блог Джейми Томсона об этой технике: Редактирование sqlcmdvariable узлов в SSDT Опубликовать файлы профиля с помощью msbuild

0 голосов
/ 24 июня 2011

Честно говоря, лучший вариант для этого - использовать концепцию миграции баз данных, пришедшую из мира Ruby, если я не ошибаюсь. В своих приложениях я использовал фреймворк Migrator.Net , но есть множество действительно хороших (с разным уровнем активности), которые в основном делают то же самое. Быстрый поиск Google показывает довольно много .

...