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

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

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

Important

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

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

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

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

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

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

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

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

Используя интеграцию и Fabric Data Warehouse Fabric Git, вы можно:

Comparison

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

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

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

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

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

Функции безопасности SQL, такие как разрешения, требуют отдельного подхода к экспорту и миграции.

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

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

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

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

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