Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Область применения: ✅ хранилище в Microsoft Fabric
Microsoft Fabric конвейеры обеспечивают упрощённый способ изменения схем складов в разных рабочих пространствах, таких как Dev → Test → Production. В конвейерах есть встроенная обработка зависимостей, проверка схем и декларативная аналитика развертывания.
Important
Эта функция доступна в предварительной версии.
В этой статье объясняется процесс развертывания складов с помощью конвейеров.
Конвейеры развертывания обеспечивают жизненный цикл, необходимый для безопасного перемещения изменений складов между рабочими пространствами. Они выступают центральным слоем оркестрации для продвижения схем, позволяя командам стандартизировать процесс изменений через аналитическую платформу, а не полагаться на разрозненные развертывания. После создания конвейер становится основным интерфейсом для сравнения складов, анализа изменений и выполнения развертываний.
Создание конвейера
Чтобы создать новый пайплайн, см. раздел «Начать с конвейеров развертывания для создания и управления конвейером развертывания».
Сравнить
Всегда проверяйте и сравнивайте изменения T-SQL перед развертыванием. Конвейеры развертывания предлагают простой экран Compare в портале Fabric для просмотра затронутых объектов склада.
Анализ изменений позволяет командам проверить готовность перед продвижением обновлений в последующих средах. Этот процесс особенно ценен в корпоративных ситуациях, где несколько команд участвуют в развитии складов.
Fabric использует DacFx (Data-tier Application Framework) для выполнения этого сравнения. DacFx строит декларативную модель схемы обеих сред и выявляет различия, такие как новые таблицы, модифицированные столбцы, ограничения или изменения зависимостей. Поскольку это сравнение основано на моделях, оно точно отражает происходящее во время развертывания.
Important
Для сравнения схем склад должен существовать как в исходном, так и в целевом рабочих пространствах. Если целевой рабочий простой ещё не содержит склад, сначала создайте или развернуте исходную версию.
Note
Если пункт столбца COLLATE явно указывает ту же колляцию, что и стандартная колляция склада, сравнение не показывает это как разницу, потому что это эквивалентно отсутствию указания колляции вовсе. В сравнениях при изменении их колляции появляются только столбцы, чья колляция отличается от стандартной составленной. Для получения дополнительной информации и примера см. Troubleshooting Git integration для Fabric Data Warehouse разработки.
Перед развертыванием изменений используйте возможность сравнения конвейера развертывания, чтобы проверить различия между исходным и целевой складскими рабочими пространствами.
Выберите «Сравнить » и просмотрите изменения, например, создайте новый вид на складе:
Deploy
После завершения сравнения и проверки изменений вы можете развернуть его напрямую через интерфейс пайплайна, выбрав элементы склада для продвижения.
Во время развертывания конвейеры развертывания используют DacFx для создания интеллектуального плана развертывания на основе различий в схемах. Fabric применяет только необходимые изменения, чтобы синхронизировать целевое рабочее пространство с исходным кодом.
Конфигурации развертывания
Fabric конвейеры развертывания используют технологию развертывания DacFx с конфигурациями, специально адаптированными для Fabric Data Warehouse. Эти конфигурации обеспечивают надёжное успешное внедрение и соответствуют возможностям платформы Fabric и операционным практикам.
Блокировка возможной потери данных (
BlockOnPossibleDataLoss = true) — Fabric Data Warehouse предотвращает развертывания, которые могут урезать, терять или иным образом потерять данные пользователей. Эта настройка предотвращает продвижение высокорисковых изменений схем между CI/CD и делает риск потери данных осознанным решением, а не тихим дефолтом.Пропуск скриптов опций на уровне базы данных (
ScriptDatabaseOptions = false) — Fabric управляет многими настройками на уровне базы данных на уровне платформы. Скриптовые операторы, такиеALTER DATABASE ... SETкак во время развертывания, могут привести к сбоям или непреднамеренному дрейфу конфигурации. Таким образом, конвейеры развертывания избегают распространения этих настроек, обеспечивая сосредоточение схем только на поддерживаемых объектах хранилища.Возможность принудительного применения для реплицированных объектов (
DoNotAlterReplicatedObjects = false) — Хранилища часто используют внутренние механизмы репликации, например, в сценариях связывания или синхронизации. Вместо преждевременного блокирования изменений схемы, конвейеры развертывания позволяют движку Fabric определить, разрешено ли изменение. Такой подход предотвращает ненужные сбои при развертывании, при этом сохраняя при этом защиту платформы.Отключение транзакционного DDL-скриптинга (
IncludeTransactionalScripts = false) — в настоящее время хранилища не поддерживают упаковку DDL-скриптов внутри транзакций. Поэтому конвейеры развертывания генерируют нетранзакционные скрипты для успешного завершения развертывания.Использование интеллектуальных стандартов для эволюции схемы (
GenerateSmartDefaults = true) — Когда изменения схемы вводят более строгие ограничения, такие как преобразование нулируемых столбцов в ненулируемые или добавление новых столбцов с ограничениями по умолчанию, конвейеры развертывания могут автоматически заполнять базовые значения. Такой подход помогает развертываниям добиваться успеха без необходимости ручной подготовки данных и снижает операционные трения во время эволюции схемы.Исключение принципов безопасности из развертывания (
ExcludeObjectTypes = Logins, Users, Permissions) — объекты безопасности намеренно исключаются из развертывания складов. Продвижение входов, пользователей или разрешений между средами может привести к рискам безопасности или конфликтам, специфичным для окружающей среды. Вместо этого управляйте контролем доступа отдельно через процессы управления средой или идентификации.Не отбрасывать объекты, не входящие в исходник (
DropObjectsNotInSource = false) — объекты, существующие в целевом объекте, но не входящие в исходник, не отбрасываются автоматически. Склады, которые полностью синхронизируют производство с контролем версий, могут считать это ограничением.
Ограничения
- По умолчанию таблица блоков системы выпадает. Процесс развертывания не отбрасывает автоматически объекты, которые существуют в целевом объекте, но не находятся в исходном коде. Такая конструкция снижает случайные потери данных и предотвращает неожиданные удаления в производстве.
- Успешное развертывание не всегда означает, что все запрошенные изменения были применёны. Развертывание может сообщать об успехе даже при пропуске запрошенного действия drop-table, поскольку удаление таблиц по умолчанию блокируется. В таком случае операция развертывания завершается, но цель всё равно может уйти из контроля исходного кода, пока вы явно не устраните недостающее изменение.
- В настоящее время процесс развертывания ставит безопасность выше строгого паритета исходного кода, не отбрасывая объекты, существующие только в целевом объекте.
- Потоки развертывания Fabric не поддерживают элемент конечной точки SQL аналитики.
- Зависимости между элементами, последовательности элементов и пробелы синхронизации между конечной точкой аналитики SQL и хранилищем влияют на рабочие процессы конвейеров развертывания Fabric.
- Выбор связанных элементов в конвейерах развертывания для Fabric Data Warehouse не поддерживается.
Устранение неполадок интеграции Git
Для ограничений, специфичных для интеграции с Git, см. раздел «Ограничения интеграции с Git » в статье об интеграции Git.
Для устранения неполадок, обходных путей и исправлений распространённых проблем интеграции Git в Fabric Data Warehouse разработке см. раздел Troubleshooting Git integration для Fabric Data Warehouse разработки.