Управление выпуском Настройка переменных DACPAC

Это не столько проблема управления релизами, сколько проблема SSDT. Вы хотите сделать что-то, что, как правило, является очень плохой идеей: сделать так, чтобы ваша база данных отличалась от среды к среде. Непрерывная доставка — это постоянство. Если вы не можете быть уверены в том, что «практикуете» свое производственное развертывание каждый раз, когда выпускаете свое программное обеспечение для более низких сред, вы настраиваете себя на действительно плохие времена, когда производственное развертывание терпит неудачу из-за различий в средах.

Тем не менее: есть несколько вещей, которые вы можете сделать, перечисленные в порядке предпочтения:

1. Перестаньте различать базу данных в разных средах
2. Поскольку вы можете использовать переменные SQLCmd в сценариях до и после развертывания, создайте сценарий после развертывания, который изменяет вашу хранимую процедуру, и передайте значение через RM. Вы можете изменить аргументы, которые RM передает в sqlpackage.exe, чтобы вы могли указать свои переменные SQLCmd во время публикации. Это все еще очень плохая идея, но она должна сработать для вас.
3. Вы можете изменить шаблон выпуска по умолчанию и переместить расположение действий по обмену токенов. Обмен токенов обычно происходит после сборки; вы можете переместить его так, чтобы оно происходило перед сборкой.

Я не вижу никакого способа, чтобы это работало с использованием файлов токенов при публикации DACPAC, поскольку RM не может вмешиваться в то, что делает sqlpackage.exe, и даже если бы это было возможно, это привело бы к остановке компиляции схемы.

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

Мой совет — применить особые требования к среде после запуска DACPAC с использованием токенизированного сценария SQL. Я описываю это в сообщении блога здесь .