Что такое интеграция Microsoft Fabric Git?
В этой статье описывается, как интегрировать управление версиями Git с средством управления жизненным циклом приложений Microsoft Fabric (ALM).
Примечание.
Некоторые элементы для интеграции с Git доступны в предварительной версии. Дополнительные сведения см. в списке поддерживаемых элементов.
Интеграция Git в Microsoft Fabric позволяет разработчикам интегрировать свои процессы разработки, инструменты и рекомендации прямо на платформу Fabric. Это позволяет разработчикам, которые работают с Fabric:
- Создание резервных копий и учет версий их работы
- Вернуться к предыдущим этапам по мере необходимости
- Совместная работа с другими пользователями или работайте в одиночку с помощью ветвей Git
- Применяйте возможности знакомых средств управления версиями для управления элементами Fabric.
См. список поддерживаемых элементов и.
Ознакомьтесь с основными понятиями Git и управления версиями.
Дополнительные сведения о процессе интеграции Git.
Ознакомьтесь с лучшим способом управления ветвями Git.
Сведения о конфиденциальности
Прежде чем включить интеграцию Git, ознакомьтесь со следующими заявлениями о конфиденциальности:
- Заявление о конфиденциальности Майкрософт
- Обзор защиты данных Azure DevOps Services
- Соглашение по защите данных GitHub
Поддерживаемые поставщики Git
Поддерживаются следующие поставщики Git:
- Git в Azure Repos с тем же клиентом , что и клиент Fabric
- GitHub (только облачные версии)
- GitHub Enterprise (только облачные версии)
Поддерживаемые элементы
В настоящее время поддерживаются следующие элементы:
- Конвейеры данных(предварительная версия)
- потоки данных 2-го поколения(предварительная версия)
- Eventhouse и база данных KQL(предварительная версия)
- EventStream(предварительная версия)
- Lakehouse(предварительная версия)
- зеркальной базы данных(предварительная версия)
- Записные книжки
- Отчеты с разбивкой на страницы(предварительная версия)
- Рефлектор (предварительная версия)
- Отчеты (за исключением отчетов, подключенных к семантическим моделям, размещенным в службах Azure Analysis Services, SQL Server Analysis Services, или отчетов, экспортированных из Power BI Desktop, которые зависят от семантических моделей, размещенных в MyWorkspace) (предварительная версия)
- Семантические модели (за исключением push-наборов данных, динамические подключения к службам Analysis Services, модель версии 1) (предварительная версия)
- Определения заданийSpark (предварительная версия)
- Среда Spark(предварительная версия)
- База данныхSQL (предварительная версия)
- Склады(предварительная версия)
Если в рабочей области или каталоге Git нет неподдерживаемых элементов, он по-прежнему может быть подключен, но неподдерживаемые элементы игнорируются. Они не сохраняются или синхронизируются, но они не удаляются. Они отображаются на панели контроля версий, но их нельзя зафиксировать или обновить.
Рекомендации и ограничения
Общие ограничения интеграции Git
- Метод проверки подлинности в Fabric должен быть не менее строгим, чем метод проверки подлинности для Git. Например, если Git требует многофакторной проверки подлинности, Структура должна также требовать многофакторную проверку подлинности.
- В настоящее время наборы данных Power BI, подключенные к службам Analysis Services, не поддерживаются.
- Рабочие области с установленными приложениями-шаблонами не могут быть подключены к Git.
- Подмодулы не поддерживаются.
- Независимые облака не поддерживаются.
- Учетная запись Azure DevOps должна быть зарегистрирована для того же пользователя, который использует рабочую область Fabric.
- Azure DevOps не поддерживается, если включена проверка политики условного доступа IP.
- Администратор клиента должен включить перекрестный экспорт , если рабочая область и репозиторий Git находятся в двух разных географических регионах.
- Если ваша организация настроила условный доступ, убедитесь в том, что для службы Power BI установлены те же условия, чтобы проверка подлинности работала как положено.
- Размер коммита ограничен 125 МБ.
Ограничения GitHub Enterprise
Некоторые параметры GitHub Enterprise не поддерживаются. Например:
- Список разрешенных IP-адресов
- Частная сеть
- Личные домены
Ограничения рабочей области
- Только администратор рабочей области может управлять подключениями к репозиторию Git, таким как подключение, отключение или добавление ветви.
После подключения любой пользователь с разрешением может работать в рабочей области.
Ограничения ветвей и папок
- Максимальная длина имени ветви составляет 244 символа.
- Максимальная длина полного пути для имен файлов составляет 250 символов. Длинные имена не работают.
- Максимальный размер файла составляет 25 МБ.
- Структура папок поддерживается до 10 уровней.
- Вы не можете скачать отчет или набор данных как PBIX из службы после их развертывания с интеграцией Git.
- Если отображаемое имя элемента обладает любыми из этих характеристик, папка Git переименовывается в логический идентификатор (GUID) и тип:
- При подключении рабочей области с папками к Git необходимо зафиксировать изменения в репозитории Git, если это структура папок отличается.
Ограничения имени каталога
Имя каталога, подключающегося к репозиторию Git, имеет следующие ограничения именования:
- Имя каталога не может начинаться или заканчиваться пробелом или вкладкой.
- Имя каталога не может содержать ни одного из следующих символов: "/:<>\*?|
Папка элемента (папка, содержащая файлы элементов), не может содержать ни одного из следующих символов: ":<>\*?|. Если вы переименовываете папку в одну из этих символов, Git не может подключиться или синхронизироваться с рабочей областью и возникает ошибка.
Ограничения роста и ветвления
- Для ветвления требуются разрешения, перечисленные в таблице разрешений.
- Для этой операции должна быть доступна возможность.
- Все ограничения именования рабочей области и ветвей применяются при создании новой рабочей области.
- В новой рабочей области доступны только элементы, поддерживаемые Git.
- В списке связанных ветвей отображаются только ветви и рабочие области, которые у вас есть разрешение на просмотр.
- Интеграция Git должна быть включена.
- При выходе из ветвления создается новая ветвь, а параметры исходной ветви не копируются. Настройте все параметры или определения, чтобы обеспечить соответствие новым политикам вашей организации.
- При переходе в существующее рабочее пространство:
- Целевая рабочая область должна поддерживать подключение Git.
- Пользователь должен быть администратором целевой рабочей области.
- Целевая рабочая область должна иметь достаточную вместимость.
- Рабочая область не может иметь приложения-шаблоны.
- Обратите внимание, что при выходе из рабочей области все элементы, которые не сохраняются в Git, могут быть потеряны. Мы рекомендуем зафиксировать элементы, которые вы хотите сохранить, перед созданием новой ветки.
Ограничения синхронизации и коммита
- Одновременно можно синхронизировать только в одном направлении. Вы не можете зафиксировать и обновить одновременно.
- Метки конфиденциальности не поддерживаются, и экспорт элементов с метками конфиденциальности может быть отключен. Чтобы зафиксировать элементы с метками конфиденциальности без метки конфиденциальности, обратитесь к администратору за помощью.
- Работает с ограниченными элементами. Неподдерживаемые элементы в папке игнорируются.
- Дублирование имен не допускается. Даже если Power BI разрешает дублирование имен, обновление, подтверждение или отмена действия завершается ошибкой.
- B2B не поддерживается.
- Разрешение конфликтов частично выполняется в Git.
- Во время процесса фиксации в Git служба Fabric удаляет файлы в папке элемента, которые не являются частью определения элемента. Не связанные файлы, не входящие в папку элемента, не удаляются.
- После фиксации изменений вы можете заметить некоторые непредвиденные изменения элемента, которые вы не вносили. Эти изменения семантически незначительны и могут произойти по нескольким причинам. Например:
- Изменение файла определения элемента вручную. Эти изменения допустимы, но могут отличаться от того, что сделано через редакторы. Например, если вы переименовываете столбец семантической модели в Git и импортируете это изменение в рабочую область, при следующей фиксации изменений в семантической модели файл bim будет регистрироваться как измененный и измененный столбец будет перемещен в конец массива
columns
. Это связано с тем, что подсистема AS, создающая файлы bim , отправляет переименованные столбцы в конец массива. Это изменение не влияет на способ работы элемента. - Коммит файла, использующего разрывы строк CRLF. Служба использует LF (разрыв строки). Если у вас есть файлы элементов в репозитории Git с разрывами строк CRLF, при фиксации из службы эти файлы изменяются на LF. Например, если открыть отчет на рабочем столе, сохраните файл проекта (PBIP) и отправьте его в Git с помощью CRLF.
- Изменение файла определения элемента вручную. Эти изменения допустимы, но могут отличаться от того, что сделано через редакторы. Например, если вы переименовываете столбец семантической модели в Git и импортируете это изменение в рабочую область, при следующей фиксации изменений в семантической модели файл bim будет регистрироваться как измененный и измененный столбец будет перемещен в конец массива
- Обновление семантической модели с помощью API расширенного обновления вызывает разницу в Git после каждого обновления.