Сборка VSTS — добавочное развертывание базы данных в распределенной среде

Убедитесь, что ваши сценарии до и после развертывания всегда идемпотентны. Однако вы хотите реализовать это зависит от вас. Скрипты должны запускаться любое количество раз и всегда давать правильные результаты. Поэтому, если ваша схема изменится, что повлияет на сценарии развертывания, обновление сценариев зависит от изменений и сопровождает их в системе управления версиями. Управление версиями вашей базы данных уже является встроенной функцией SSDT. В самом файле проекта есть узел для версии. И в VSTS есть множество задач по сборке версий, которые вы также можете использовать бесплатно для создания версий. Когда SqlPackage.exe публикует ваш проект с уже установленной версией базы данных, запись обновляется в msdb.dbo.sysdac_instances. Это намного проще, чем пытаться управлять, обновлять и т. д. вашу собственную доморощенную версию решения. И вы не загромождаете базу данных своего приложения таблицами и другими объектами, не связанными с самим приложением. Я согласен с тем, чтобы информация о спринте не вмешивалась. В наших проектах я помечаю исходный код успешных сборок номером сборки, что, конечно же, создает временной маркер в исходном коде, связанный с конкретной сборкой.

Я бы предложил использовать операторы MERGE вместо вставки. Таким образом, вы защищены от повторяющихся вставок в рамках спринта.

Следующее, как различать разные вставки для разных спринтов. Я бы предложил реализовать нумерацию версий для синхронизации базы данных со спринтами. Итак, создайте таблицу DbVersion (версия int). Затем в сценарии после развертывания сделайте что-то вроде этого:

SET @version = SELECT ISNULL(MAX(version), 0) FROM DbVersion 
IF @version < 1
 --inserts/merge for sprint 1
IF @version < 2
 --inserts/merge for sprint 2
...
INSERT INTO DbVersion(@currentVersion)

Что я сделал в большинстве проектов, так это создал MERGE скриптов, по одному на таблицу, которые заполняют "основные" или "статические" данные. Существуют такие инструменты, как https://github.com/readyroll/generate-sql-merge, который можно использовать для создания этих скриптов.

Они вызываются из сценария после развертывания, а не в действии после сборки. Обычно я создаю один (в любом случае вам разрешен только один!) сценарий после развертывания для проекта, а затем включаю все отдельные сценарии статических данных, используя синтаксис :r. Сценарий после развертывания — это просто файл .sql с действием сборки «Пост-развертывание», его можно создать «вручную» или с помощью диалогового окна «Добавить новый объект» в SSDT и выбора «Сценарий» -> «Сценарий после развертывания».

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

Когда вы создаете dacpac, все основные данные будут включены, и, поскольку вы используете merge, а не вставку, вам гарантируется, что в конце развертывания содержимое таблиц будет соответствовать < em>содержимое вашей системы управления версиями, точно так же, как SSDT/sqlpackage гарантирует, что структура ваших таблиц соответствует структуре их определений в системе управления версиями.

Я не понимаю, как сюда входит понятие «спринт», если только «спринт» не означает «выпуск»; в этом случае dacpac, созданный и выпущенный в конце спринта, будет содержать все изменения, как структурные, так и «основные данные», добавленные во время спринта. Я думаю, что было бы разумно держать понятие «спринт» подальше от системы управления версиями!