Интеграция с Git для разработки хранилищ в Fabric

Область применения: ✅ хранилище в Microsoft Fabric

В этой статье рассматриваются преимущества разработки и развертывания Fabric Data Warehouse со встроенной интеграцией Git в Fabric.

Important

Эта функция доступна в предварительной версии.

Используя интеграцию с Git в Fabric, команды могут применять современные методы контроля версий для разработки складов. Разработчики могут изолировать изменения в ветках, отслеживать эволюцию схем через коммиты, сотрудничать через pull requests и синхронизировать обновления между репозиториями Git и рабочими пространствами Fabric.

К типичным сценариям относятся:

  • Безопасная разработка изменений схемы в ветках и рабочих пространствах
  • Версионирование объектов хранилища данных в Git
  • Сотрудничество между несколькими филиалами и рабочими пространствами
  • Продвижение валидированных изменений между филиалами
  • Поддержание элементов рабочего пространства (warehouse и других) синхронизированными с единым источником истины в Git

Чтобы поддерживать последовательность, отслеживаемость и надёжность на протяжении всех жизненных циклов разработки склада, необходимо понимать эти рабочие процессы.

Схема жизненного цикла разработки интеграции Git с Fabric Warehouse.

Когда вы подключаете рабочее пространство Fabric Data Warehouse к Git, вы фиксируете определения хранилища в виде проекта базы данных. Этот проект становится эталонным представлением схемы хранилища данных в системе контроля версий и служит основой для дальнейшей разработки. В обозревателе системы управления версиями схема отображается в виде отдельных файлов .sql.

Скриншот схемы хранилища в проводнике контроля версий.

Используя Fabric Git Integration и Fabric Data Warehouse, вы можете:

Comparison

В процессе синхронизации Fabric использует развертывание инкрементальных схем на основе DacFx для внесения изменений. Этот подход применяет только соответствующие различия схемы к складу, а не обновляет всё определение склада.

Инкрементальная экстракция помогает сократить лишние изменения в системе контроля версий, поддерживать более чистые различия между версиями схем в разных ветвях и обеспечивать эффективные процессы ветвления и слияния. Поскольку процесс извлечения ориентирован на схему, он также позволяет надёжно сравнивать и проверять состояние рабочего пространства и определения, отслеживаемые через Git.

Стандартизация способов извлечения и хранения складских схем повышает согласованность между средами разработки. Определения схем остаются стабильными между ветвями, различия точнее отражают намеренные изменения разработки, а контроль исходного кодов становится надёжной базой для развертывания, сотрудничества и управления жизненным циклом.

XMLA.json Сам файл исключается из процессов интеграции Git. Fabric исключает этот файл из коммитов и обновлений, чтобы стандартные семантические model метаданные не хранились случайно в Git. При синхронизации рабочего пространства с Git игнорируется XMLA.json , что помогает избежать конфликтов, непреднамеренной перезаписи и шума при переключении веток или обновлениях с Git.

Ограничения в системе управления версиями

  • Функции безопасности SQL, такие как разрешения, требуют скриптового подхода для экспорта и миграции. Рассмотрите возможность использования скрипта после развертывания в проекте базы данных SQL. Вы можете настроить скрипт после развертывания в проекте с помощью расширения SQL Database Projects, доступного в Visual Studio Code.

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

  • Скрипты до или после развертывания, а также дополнительные конфигурации публикации, добавленные непосредственно в проект базы данных через Git, не сохраняются в рамках рабочих процессов разработки. Возможно, вам придётся управлять этими конфигурациями отдельно вне Fabric workspace.

  • Селективные коммиты на уровне склада сейчас не поддерживаются. Изменения фиксируются на уровне товара склада, а не на более мелком уровне объектов.

  • Поддержка контроля версий для конечных точек SQL analytics в настоящее время недоступна. Это ограничение может ограничивать управление сквозным жизненным циклом, когда решения охватывают как склады, так и конечные точки аналитики SQL.

Ограничения интеграции Git

  • Когда два или более складских товаров ссылаются друг на друга, они образуют циклическую зависимость. Система обнаруживает этот круговой отсыл во время операций разветвления или синхронизации Git-to-workspace, что приводит к отказу этих операций. Избегайте циклических зависимостей между элементами.
  • В настоящее время не создавайте поток данных 2-го поколения с назначением выходных данных в хранилище. Новый элемент с именем DataflowsStagingWarehouse появляется в репозитории и блокирует коммит и обновление из Git.
  • Перекрестные зависимости элементов, последовательности элементов и пробелы синхронизации между конечной точкой аналитики SQL и хранилищем влияют на "ветвление в новую или существующую рабочую область" и "переключение на другую ветвь" рабочих процессов во время разработки и непрерывной интеграции.
  • Если объект ссылается на другой объект в том же хранилище с помощью трёхчастного именования (database.schema.object), фиксация или обновление из Git может не получиться. Для получения дополнительной информации и обходного пути см. раздел «Ссылки на собственные объекты склада с использованием трёхчастного названия».
  • Если изменить столбец, для которого определён IDENTITY, фиксация изменений или обновление из Git могут завершиться с ошибкой, пока для таблицы не будет включён IDENTITY_INSERT.
  • Если репозиторий содержит файл .sqlproj, фиксирующий более старую версию SDK Microsoft.Build.Sql, фиксация изменений или обновление из Git могут завершиться сбоем, поскольку старая версия SDK не распознаёт более новый синтаксис хранилища данных, например столбцы IDENTITY и CLUSTER BY. Для получения дополнительной информации и обходного пути смотрите раздел Out-of-date .sqlproj в репозитории Git.
  • Если объект ссылается на две или более таблиц в другом хранилище и для каждого столбца не указан псевдоним, фиксация изменений или обновление из Git может завершиться с ошибкой. Для получения дополнительной информации и сведений о временном решении см. «Неквалифицированные столбцы в объектах, ссылающихся на две или более таблицы в другом хранилище».
  • Если ваши скрипты ссылаются на два или более разных объекта в одной схеме другого склада и пишут название схемы с непоследовательной заглавной буквой, фиксация или обновление из Git может не получиться. Для получения дополнительной информации и обходного пути см. раздел «Несогласованное написание заглавных букв имён схем».
  • Ошибки неоднозначности столбцов, в списке вариантов которых присутствует разделитель ::, могут возникать при выполнении commit или обновления из Git, даже при отсутствии фактической неоднозначности. Для получения дополнительной информации и временных решений см. раздел «Ошибки неоднозначности столбцов при наличии повторяющихся объектов-кандидатов».

Неподдерживаемые сценарии

Следующие рабочие процессы CI/CD официально не поддерживаются при наличии разных параметров сортировки в хранилищах в разных рабочих областях. Несмотря на то, что эти операции могут выполняться без ошибок, они могут привести к ошибкам метаданных.

Во всех этих сценариях, если возникает несоответствие сортировок, используйте скрипт Python scripts/dw-collation-error-update-tmsl/pbi_interactive.py в репозитории Fabric GitHub для обновления сортировки набора данных (TMSL) для соответствия сортировке хранилища.

Сценарий Description Риск
Цепочки развертывания Продвижение содержимого хранилища с помощью этапов конвейера (например, тест разработки → Test → Prod), где целевое хранилище было создано с другой сортировкой, отличной от источника, не поддерживается. Развертывание может завершиться успешно, но параметры сортировки набора данных не обновляются для сопоставления сортировки целевого хранилища.
Разветвление в новое или существующее рабочее пространство Использование интеграции Git для ветвления из существующей рабочей области в новую или существующую рабочую область, в которой хранилище имеет другую сортировку, не поддерживается. Содержимое хранилища синхронизируется, но метаданные сортировки не согласованы.
Переключение ветвей в рабочей области Переключение на ветвь, связанную с хранилищем другой сортировки в рабочей области, подключенной к Git, не поддерживается. Синхронизированное содержимое может переносить предположения о сортировке, которые не соответствуют текущему хранилищу.
Объединение изменений между рабочими областями с помощью ветвей Объединение ветвей Git между рабочими пространствами, в которых базы данных имеют разные параметры сортировки, не поддерживается. Слияние может завершиться успешно на уровне Git, но результирующая сортировка набора данных не отражает параметры сортировки целевого хранилища.

Следующий шаг

Используйте интеграцию с Git для разработки и развертывания складов

Связанные материалы

  • Last updated on