Управление версиями, CI/CD и ALM для агента данных Fabric

В этой статье описывается, как управлять агентами данных Fabric с помощью конвейеров интеграции и развертывания Git в рамках возможностей управления жизненным циклом приложений Microsoft Fabric (ALM). Вы узнаете, как подключить рабочую область к репозиторию Git. Вы также узнаете, как отслеживать и версионировать конфигурации агента данных. Наконец, вы узнаете, как повысить уровень обновлений в средах разработки, тестирования и рабочей среды. Конвейеры интеграции и развертывания Git позволяют выполнять непрерывную интеграцию и непрерывное развертывание (CI/CD) изменений агента данных, что позволяет тестировать и продвигать обновления автоматически в рамках рабочего процесса ALM. Системы контроля версий для агентов данных Fabric в настоящее время находятся в предварительной версии.

Вы можете использовать два дополнительных подхода для поддержки ALM для агентов данных Fabric:

Интеграция Git: синхронизируйте всю рабочую область с репозиторием Git (Azure DevOps или GitHub в качестве поставщика Git), чтобы включить управление версиями, совместную работу с помощью ветвей и отслеживание журнала отдельных элементов, включая агенты данных Fabric.
Конвейеры развертывания. Продвижение содержимого между отдельными рабочими областями, представляющими этапы разработки, тестирования и рабочей среды, осуществляется с помощью встроенных конвейеров.

Эти возможности вместе обеспечивают сквозную поддержку ALM для агентов данных Fabric.

Предпосылки

Платная емкость Fabric F2 или более высокой или Power BI Premium для емкости (P1 или выше) с включенной функцией Microsoft Fabric.
Включите межрегиональную обработку и межрегиональное хранение для искусственного интеллекта на основе требований, описанных в настройках клиента агента данных Fabric.
По крайней мере один из этих источников данных с данными: хранилище, lakehouse (озеро данных), семантическая модель Power BI, база данных KQL, зеркальная база данных или онтология. У вас должен быть доступ на чтение к источнику данных.

Интеграция с Git

Интеграция с Git в Microsoft Fabric синхронизирует рабочую область Fabric с репозиторием Git, позволяя использовать существующие процессы разработки, инструментальные средства и передовую практику непосредственно на платформе Fabric. Она поддерживает Azure DevOps и GitHub и доступна на уровне рабочей области. При фиксации изменений из Fabric, включая обновления конфигурации агента данных, эти изменения сохраняются в виде файлов в подключенном репозитории Git. К ее ключевым возможностям относятся:

Полное управление резервным копированием и версиями элементов рабочей области
Структура папок в Git отражает структуру рабочей области
Конфигурации агента данных (выбор схемы, инструкции ИИ, инструкции по источнику данных, примеры запросов) хранятся в структурированных файлах в выделенных папках
Возможность просматривать различия, проверять историю и восстанавливать предыдущие состояния через журнал истории для различных элементов рабочей области, включая агентов данных.
Совместная работа на основе филиалов (ветви компонентов, main)

Последние улучшения интеграции Git

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

Дополнительные сведения о процессе интеграции Git см. в следующих ресурсах.

Настройка подключения к системе контроля версий

Вы можете подключить рабочую область Fabric к репозиторию Git на странице параметров Workspace. Это подключение позволяет зафиксировать и синхронизировать изменения непосредственно из Fabric.

Подробные инструкции по подключению к репозиторию Git см. в разделе Начало работы с интеграцией Git для подключения к репозиторию Git в Azure DevOps или GitHub.
После подключения к репозиторию Git элементы рабочей области, включая агенты данных Fabric, отображаются на панели управления версиями исходного кода. В строке состояния в левом нижнем углу можно увидеть имя подключенной ветви, время последней синхронизации и идентификатор фиксации Git.

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

При внесении изменений в агент данных Fabric в рабочей области, подключенной к Git, изменения фиксируются, и статус агента данных в области управления версиями изменяется на "Не зафиксированные изменения". Эти изменения могут включать:
- Изменение выбора схемы.
- Обновление инструкций по ИИ или инструкций по источнику данных.
- Редактирование примеров запросов.
- Публикация агента данных или обновление описания публикации.

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

Когда обновления выполняются непосредственно в связанном репозитории Git (Azure DevOps или GitHub), они могут включать такие действия, как изменение инструкций ИИ, изменение примеров запросов или редактирование описания публикации. Затем вы можете зафиксировать и отправить эти изменения в репозиторий. После того как обновления отправлены и становятся доступными в репозитории Fabric, ваша рабочая область обнаруживает их и отображает уведомление о доступных обновлениях на панели управления исходным кодом. Обновленные элементы, такие как агент данных, отображаются на вкладке "Обновления", где их можно просмотреть и принять. Принятие этих обновлений применяет изменения репозитория к элементам рабочей области, гарантируя, что рабочая область отражает последнюю зафиксированную версию в Git.

Структура папок и файлов в репозитории Git

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

Корневая структура

В корневом каталоге содержимое агента данных хранится в папке файлов . В файлах вы найдете папку конфигурации , содержащую data_agent.json, publish_info.json, черновик и опубликованную папку.

В папке config находится файл publish_info.json, который содержит описание публикации агента данных. Этот файл можно обновить, чтобы изменить описание, которое отображается при публикации агента данных.

Папка черновика содержит файлы конфигурации, соответствующие черновику агента данных, и опубликованная папка содержит файлы конфигурации для опубликованной версии агента данных. Папка черновика содержит следующее:

Папки источника данных , в которых есть одна папка для каждого источника данных, используемого агентом данных. Имя каждой папки начинается с префикса, указывающего тип источника данных, за которым следует имя источника данных. Рассмотрим пример.
- Источники данных Lakehouse или хранилища: имена папок начинаются с lakehouse-tables- или warehouse-tables-, впоследствии указывается имя лейкхаус или хранилище.
- Источники данных семантической модели: имена папок начинаются с semantic-model-имени семантической модели.
- Источники данных базы данных KQL: имена папок начинаются с kusto-имени базы данных KQL.
- Источники данных ontology: имена папок начинаются с ontology-, а затем имя онтологии.
Другие поддерживаемые источники данных, такие как базы данных SQL в Fabric, зеркальные базы данных, модели графов и Поиск с использованием ИИ Azure, следуют той же схеме именования. Полный список поддерживаемых источников данных см. Добавить и настроить источники данных в Fabric data agent.

stage_config.json, который содержит aiInstructions, представляющий инструкции агента.

Каждая папка источника данных содержит datasource.json и fewshots.json. Однако если источник данных является семантической моделью, он не поддерживает примеры запросов, поэтому ее папка содержит только datasource.json.

datasource.json определяет конфигурацию для этого источника данных, в том числе:

dataSourceInstructions, представляющий инструкции, указанные для этого источника данных.
displayName— имя источника данных.
elements, который ссылается на карту схемы и включает полный список таблиц и столбцов из источника данных.
- Каждая таблица имеет is_selected свойство. Если true, таблица включена, и если false, это значит, что таблица не выбрана и не будет использоваться агентом данных.
- Записи столбцов также показывают is_selected, но выбор на уровне столбца в настоящее время не поддерживается. Если выбрана таблица, все его столбцы включаются независимо от значения столбца is_selected . Если таблица не выбрана (is_selected на уровне таблицы false), ни один из столбцов не учитывается, несмотря на то, что is_selected имеет значение true на уровне столбца.
Соглашения о типах:
- Если тип является источником данных, это просто тип источника данных (например: "type": "lakehouse_tables").
- Если тип является таблицей, она заканчивается .table (например: "type": "lakehouse_tables.table").
- Если тип является столбцом, он заканчивается .column (например: "type": "lakehouse_tables.column").

В fewshots.jsonхранятся примеры запросов к источнику данных. Каждая запись включает:

id в качестве уникального идентификатора для примера запроса.
question, что относится к вопросу естественного языка.
query отображает текст запроса, который может быть SQL или KQL в зависимости от типа источника данных.

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

Конвейеры развертывания для агентов данных

Конвейеры развертывания обеспечивают управляемый способ перемещения агентов данных между рабочими областями, сопоставленными с разными этапами жизненного цикла. Рассмотрим пример.

Разработка нового агента данных или обновление существующей в рабочей области разработки.
Повышение уровня изменений в тестовой рабочей области для проверки.
Внедряйте тестированные изменения в производственную среду, где они будут доступны конечным пользователям.

Перед развертыванием необходимо назначить рабочее пространство каждому этапу в конвейере развертывания: разработка, тестирование и эксплуатация. Если вы не назначите рабочие области для тестовой или продуктивной стадии, они создадутся автоматически. Автоматически созданные рабочие области называются рабочей областью разработки с добавлением [test] или [prod].

Чтобы развернуть изменения, выполните приведенные действия.

На этапе конвейера перейдите к стадии, из которой требуется выполнить развертывание (например, на стадии разработки).
Выберите элементы в рабочей области, которые вы хотите развернуть.
Выберите "Развертывание", чтобы продвинуть их на следующий этап.

Перед применением изменений можно просмотреть план развертывания, чтобы обеспечить, что только предполагаемые обновления были продвинуты. Дополнительные сведения см. в статье «Начало работы с конвейерами развертывания».

Автоматизация CI/CD с помощью конвейеров Azure DevOps

Расширение Azure DevOps Pipelines для Fabric предоставляет встроенные задачи, которые выполняют команды Fabric CLI в заданиях конвейеров Azure DevOps. Команды могут оркестровать CI/CD для обновлений агента данных с помощью Azure DevOps (со средой командной строки) наряду или вместо конвейеров развертывания Fabric. Чтобы приступить к работе, установите расширение из Visual Studio Marketplace, настройте подключение службы для вашего проекта Azure DevOps и добавьте задачи Fabric CLI в определение вашего конвейера.

Массовая синхронизация с помощью пакетных API (предварительный просмотр)

Api пакетной службы импорта и экспорта определений элементов (предварительная версия) предоставляют возможность крупномасштабной синхронизации определений элементов, включая конфигурации агента данных. Вы можете экспортировать и импортировать определения агента данных пакетно, чтобы упростить процесс продвижения в различных средах. Дополнительные сведения см. в документации Fabric REST API.

Замечание

Субъекты-службы поддерживаются в Fabric агенте данных only в рамках сценариев ALM. Эта поддержка ограничивается активацией операций ALM (таких как интеграция с Git и конвейеры развертывания) и не распространяется на другие функции агента данных Fabric. Если вам нужно взаимодействовать с агентом данных вне рабочих процессов ALM, служебный принципал не поддерживается.

Публикация агента данных Fabric для конвейеров развертывания

Публикация агента данных Fabric делает его доступным для использования во всех разных каналах потребления, включая Copilot для Power BI, Microsoft Copilot Studio и средств Foundry. Чтобы оценить и использовать агент данных в этих каналах, необходимо опубликовать агент данных; Неопубликованные агенты данных недоступны для использования, даже если они находятся в рабочей рабочей области. Чтобы следовать лучшим практикам в соответствии с конвейером развертывания, обратите внимание на следующее:

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

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

Лучшие практики

Используйте отдельную ветвь для разработки агентов данных и выполните слияние с ветвью main после проверки кода.
Сохраняйте связанные ресурсы (источники данных, агенты данных, записные книжки, конвейеры) в той же рабочей области, чтобы упростить повышение уровня.
Тестирование изменений агента данных в тестовой рабочей области перед продвижением в рабочую среду.
Используйте описательные сообщения фиксации, чтобы упростить понимание истории.
Не вносите изменения непосредственно в опубликованную папку в репозитории Git.
Используйте шаблоны конфигурации, не зависящие от среды (например, ссылки на подключения через библиотеку переменных, где поддерживается), чтобы избежать жесткого определения значений среды в конфигурациях источника данных агента данных. Эта практика упрощает слияние веток и развертывание между средами разработки, тестирования и производства.

Ограничения и рекомендации

Только рабочие области, подключенные к репозиторию Git, могут использовать функции ALM на основе Git.
Принципы службы поддерживаются в агенте данных Fabric только как часть сценариев управления жизненным циклом приложений (ALM). Если вам нужно взаимодействовать с агентом данных вне рабочих процессов ALM, служебный принципал не поддерживается.
Конвейеры развертывания требуют, чтобы исходные и целевые рабочие области были в одном арендаторе.
Большое количество частых коммитов может влиять на размер репозитория и его производительность.

Обратная связь

Были ли сведения на этой странице полезными?

Последнее обновление: 2026-08-27