Controlo de Versão, CI/CD e ALM para o agente de dados do Fabric

Este artigo descreve como gerir agentes de dados Fabric utilizando pipelines de integração e implementação do Git, como parte das capacidades de Gestão do Ciclo de Vida de Aplicações (ALM) do Microsoft Fabric. Você aprende a conectar um espaço de trabalho a um repositório Git. Vai também aprender a acompanhar e a fazer o versionamento das configurações do agente de dados. Por fim, vai aprender a promover atualizações em ambientes de desenvolvimento, teste e produção. Os pipelines de integração e implantação do Git permitem a integração contínua e a implantação contínua (CI/CD) de alterações no agente de dados, permitindo que as atualizações sejam testadas e promovidas automaticamente como parte do seu fluxo de trabalho de ALM. O controlo de origem para agentes de dados Fabric encontra-se atualmente em pré-visualização.

Pode usar duas abordagens complementares para suportar ALM para agentes de dados Fabric:

Integração Git: Sincronizar todo um espaço de trabalho com um repositório Git (seja Azure DevOps ou GitHub como fornecedor Git) para permitir controlo de versões, colaboração através de branches e rastreio de histórico para itens individuais, incluindo agentes de dados Fabric.
Pipelines de implantação: promova conteúdo entre espaços de trabalho separados que representam estágios de desenvolvimento, teste e produção usando pipelines internos.

Estas capacidades, em conjunto, fornecem suporte de ALM de ponta a ponta para agentes de dados Fabric.

Pré-requisitos

Uma capacidade paga F2 ou superior do Fabric, ou uma capacidade do Power BI Premium (P1 ou superior) com Microsoft Fabric ativado.
Permita o processamento e armazenamento entre geografias para IA com base nos requisitos explicados nas configurações do inquilino do agente de dados do Fabric.
Pelo menos uma destas fontes de dados, com dados: um armazém, uma casa de lago, um modelo semântico Power BI, uma base de dados KQL, uma base de dados espelhada ou uma ontologia. Deve ter acesso de leitura à fonte de dados.

Integração Git

A integração do Microsoft Fabric Git sincroniza um espaço de trabalho Fabric com um repositório Git, permitindo-lhe usar os seus processos de desenvolvimento, ferramentas e melhores práticas existentes diretamente na plataforma Fabric. Suporta Azure DevOps e GitHub e está disponível ao nível do espaço de trabalho. Quando faz commit das alterações a partir do Fabric, incluindo atualizações na configuração do agente de dados, essas alterações são guardadas como ficheiros no repositório Git conectado. As suas principais capacidades incluem:

Backup completo e controle de versão de itens do espaço de trabalho
A estrutura de pastas no Git espelha a estrutura do espaço de trabalho
As configurações do agente de dados (seleção de esquema, instruções de IA, instruções de fonte de dados, consultas de exemplo) são armazenadas em arquivos estruturados em pastas dedicadas
Capacidade de visualizar diferenças, revisar o histórico e reverter para estados anteriores por meio do histórico para diferentes itens do espaço de trabalho, incluindo agentes de dados
Colaboração baseada em ramificações (ramificações de funcionalidades, ramo principal)

Melhorias mais recentes na integração Git

A integração do Fabric Git suporta agora ramificações seletivas, permitindo alternar a ramificação ligada ao nível do espaço de trabalho para alinhar com os fluxos de trabalho das ramificações de funcionalidades. O painel de controlo de versões também oferece uma experiência de comparação incorporada para alterações de itens, para que possa rever exatamente o que mudou antes de efetuar ou extrair atualizações. Os espaços de trabalho ramificados são mais claramente indicados na interface do Fabric, facilitando a identificação de cada ramo a que cada espaço está ligado.

Para obter mais informações sobre o processo de integração do Git, consulte os seguintes recursos.

Configurar uma conexão com o controle do código-fonte

Pode ligar o seu Fabric workspace a um repositório Git a partir da página Definições do Workspace. Esta ligação permite-te fazer commit e sincronizar as alterações diretamente do Fabric.

Consulte Comece com integração com Git para passos detalhados para se ligar a um repositório Git em Azure DevOps ou GitHub.
Depois de se ligar ao repositório Git, os itens do seu espaço de trabalho, incluindo os agentes de dados Fabric, aparecem no painel de controlo de versão. Na barra de status no canto inferior esquerdo, você pode ver o nome da ramificação conectada, a hora da última sincronização e o ID de confirmação do Git.

O repositório Git ligado apresenta uma estrutura de pastas que representa os itens do seu espaço de trabalho, incluindo os agentes de dados do Fabric e os seus ficheiros de configuração. Cada agente de dados é armazenado em sua própria pasta, permitindo que você revise as alterações, acompanhe o histórico de versões e use fluxos de trabalho do Git, como a criação de solicitações pull para mesclar atualizações em sua ramificação principal.

Quando faz modificações ao agente de dados Fabric num espaço de trabalho ligado ao Git, as alterações são detetadas e o estado do agente de dados no painel de controlo de versões muda para Alterações não confirmadas. Essas modificações podem incluir:
- Modificando a seleção de esquema.
- Atualização de instruções de IA ou instruções de fonte de dados.
- Edição de consultas de exemplo.
- Publicar o agente de dados ou atualizar sua descrição de publicação.

Qualquer alteração, seja funcional ou descritiva, faz com que o agente de dados fique fora de sincronia com o repositório Git vinculado. Os itens do espaço de trabalho com alterações aparecerão na guia Alterações no painel Controle do código-fonte. Você pode revisar essas alterações, compará-las com a versão confirmada e confirmá-las de volta ao repositório Git para sincronização.

Quando as atualizações são feitas diretamente no repositório Git ligado (Azure DevOps ou GitHub), podem incluir ações como modificar instruções de IA, alterar consultas de exemplo ou editar descrições de publicação. Em seguida, você pode confirmar e enviar essas alterações por push para o repositório. Assim que as atualizações são enviadas e estão disponíveis no repositório, o seu espaço de trabalho Fabric deteta-as e exibe uma notificação de Atualizações disponíveis no painel de controlo de origem. Os itens atualizados, como o agente de dados, aparecem na guia Atualizações, onde você pode revisá-los e aceitá-los. Aceitar essas atualizações aplica as alterações do repositório aos itens do seu espaço de trabalho, garantindo que o espaço de trabalho reflita a versão confirmada mais recente no Git.

Estrutura de pastas e arquivos no repositório Git

A seguir, revê a estrutura de como a configuração de um agente de dados é armazenada num repositório Git. Entender essa estrutura é importante para gerenciar mudanças e seguir as melhores práticas. Ao usar ramos de funcionalidades, faça alterações no ramo associado ao espaço de trabalho, reveja as diferenças no painel de controlo de versões e faça a fusão através de pull requests para promoção controlada. Os ficheiros e a estrutura de configuração dos agentes de dados mantêm-se os mesmos entre os ramos.

Estrutura radicular

Na raiz, o conteúdo do agente de dados é armazenado na pasta de arquivos . Dentro de arquivos, você encontra uma pasta de configuração , que contém data_agent.json, publish_info.json, pasta de rascunho e pasta publicada.

Dentro da pasta config , o publish_info.json contém a descrição de publicação para o agente de dados. Esse arquivo pode ser atualizado para alterar a descrição que aparece quando o agente de dados é publicado.

A pasta de rascunho contém os arquivos de configuração correspondentes à versão de rascunho do agente de dados e a pasta publicada contém os arquivos de configuração para a versão publicada do agente de dados. A pasta de rascunho contém:

Pastas de fonte de dados onde há uma pasta para cada fonte de dados usada pelo agente de dados.
- Lakehouse ou fontes de dados de Warehouse: Os nomes das pastas começam com lakehouse-tables- ou warehouse-tables-, seguidos pelo nome do lakehouse ou warehouse.
- Fontes de dados do modelo semântico: os nomes das pastas começam com semantic-model-, seguido pelo nome do modelo semântico.
- Fontes de dados do banco de dados KQL: Os nomes das pastas começam com kusto-, seguido pelo nome do banco de dados KQL.
- Fontes de dados ontológicas: Os nomes das pastas começam por ontology-, seguido do nome da ontologia.

stage_config.json que contém aiInstructions, que se refere às instruções do agente.

Cada pasta de fonte de dados contém datasource.json e fewshots.json. No entanto, se a fonte de dados for um modelo semântico, ela não oferece suporte a consultas de exemplo, portanto, sua pasta contém apenas datasource.json.

O datasource.json define a configuração dessa fonte de dados, incluindo:

dataSourceInstructions, que representa as instruções fornecidas para essa fonte de dados.
displayName, que mostra o nome da fonte de dados.
elements, que se refere ao mapa de esquema e inclui uma lista completa de tabelas e colunas da fonte de dados.
- Cada mesa tem uma is_selected propriedade. Se true, a tabela estiver incluída e se false, significa que a tabela não está selecionada e não será usada pelo agente de dados.
- As entradas das colunas também mostram is_selected, mas a seleção ao nível da coluna não é atualmente suportada. Se uma tabela for selecionada, todas as suas colunas serão incluídas, independentemente do valor da coluna is_selected . Se uma tabela não for selecionada (is_selected: false no nível da tabela), nenhuma das colunas será considerada, apesar de estar is_selected definida como true no nível da coluna.
Convenções de tipo:
- Se o tipo for uma fonte de dados, é simplesmente o tipo de fonte de dados (por exemplo: "type": "lakehouse_tables").
- Se o tipo for uma tabela, termina com .table (por exemplo: "type": "lakehouse_tables.table").
- Se o tipo for uma coluna, termina com .column (por exemplo: "type": "lakehouse_tables.column").

O fewshots.json armazena consultas de exemplo para a fonte de dados. Cada entrada inclui:

id como o identificador exclusivo para a consulta de exemplo.
question, que se refere à questão da linguagem natural.
query mostra o texto da consulta, que pode ser SQL ou KQL, dependendo do tipo de fonte de dados.

A pasta publicada espelha a estrutura da pasta de rascunho, mas representa a versão publicada do agente de dados. É uma prática recomendada não modificar arquivos diretamente na pasta publicada. As alterações devem ser feitas na pasta de rascunho. Uma vez que o agente de dados é publicado, essas alterações são refletidas na pasta publicada. Isso garante que a versão publicada seja sempre gerada a partir de um estado de rascunho controlado.

Pipelines de implantação para agentes de dados

Os pipelines de implantação fornecem uma maneira controlada de mover agentes de dados entre espaços de trabalho mapeados para diferentes estágios do ciclo de vida. Por exemplo:

Desenvolva um novo agente de dados ou atualize um existente no espaço de trabalho de desenvolvimento.
Promova as alterações no espaço de trabalho de teste para validação.
Promova as alterações testadas no espaço de trabalho de produção onde ele está disponível para os usuários finais.

Antes de implantar, você precisa atribuir um espaço de trabalho a cada estágio do pipeline de implantação: desenvolvimento, teste e produção. Se não atribuires um espaço de trabalho à fase de teste ou produção, os espaços de trabalho são criados automaticamente. Os espaços de trabalho criados automaticamente são nomeados após o espaço de trabalho de desenvolvimento, com [test] ou [prod] anexado.

Para implantar alterações:

No pipeline, vá para o estágio a partir do qual você deseja implantar (por exemplo, desenvolvimento).
Selecione os itens no espaço de trabalho que você deseja implantar.
Selecione Implementar para promovê-los para a próxima etapa.

Você pode revisar um plano de implantação antes de aplicar as alterações, garantindo que apenas as atualizações pretendidas sejam promovidas. Para obter mais informações, consulte Introdução aos pipelines de implantação.

Automatizar CI/CD com Azure DevOps Pipelines

A extensão Azure DevOps Pipelines para Fabric fornece tarefas nativas que executam comandos Fabric CLI em trabalhos de pipeline do Azure DevOps. As equipas podem orquestrar CI/CD para atualizações de agentes de dados usando Azure DevOps (com a linha de comandos) juntamente com ou em vez de pipelines de implementação do Fabric. Para começar, instale a extensão no Visual Studio Marketplace, configure uma ligação de serviço no seu projeto Azure DevOps e adicione tarefas de CLI Fabric à definição do pipeline.

Sincronização em massa via APIs em lote (pré-visualização)

As APIs Batch de Importação/Exportação de Definições de Itens (pré-visualização) oferecem uma opção para sincronização em larga escala das definições de itens, incluindo configurações de agentes de dados. Pode exportar e importar definições de agentes de dados em lote para agilizar a promoção entre ambientes. Para mais informações, consulte a documentação da API REST Fabric.

Observação

Entidades de serviço são suportadas no agente de dados Fabric apenas como parte dos cenários ALM. Este suporte limita-se a permitir operações ALM (como pipelines de integração e implementação do Git) e não se estende a outras funcionalidades do agente de dados Fabric. Se você precisar interagir com um agente de dados fora dos fluxos de trabalho do ALM, a entidade de serviço não será suportada.

Publique um agente de dados Fabric para os pipelines de implementação

A publicação de um agente de dados Fabric torna-o disponível para uso em todos os canais de consumo, incluindo Copilot para Power BI, Microsoft Copilot Studio e Foundry Tools. Para avaliar e consumir o agente de dados nesses canais, o agente de dados deve ser publicado; os agentes de dados não publicados não estão acessíveis para consumo, ainda que estejam no espaço de trabalho de produção. Para seguir as melhores práticas de acordo com o pipeline de implantação, observe que:

A publicação a partir de um espaço de trabalho de desenvolvimento deve ser limitada apenas a usuários autorizados que estejam trabalhando no desenvolvimento de agentes de dados e queiram avaliar seu desempenho em diferentes canais de consumo. O acesso a esse espaço de trabalho deve ser restrito para que agentes de dados inacabados ou experimentais não sejam expostos a públicos mais amplos.
Os usuários finais devem acessar os agentes de dados publicados somente a partir do espaço de trabalho de produção, garantindo que interajam com versões estáveis e aprovadas do agente de dados.

Essa abordagem suporta o requisito funcional de permitir a avaliação de consumo e desempenho, e garante o controle de acesso adequado, mantendo os ambientes de desenvolvimento e produção separados.

Melhores práticas

Use uma ramificação dedicada para o trabalho de desenvolvimento em agentes de dados e mescle para principal após a revisão de código.
Mantenha os recursos relacionados (fontes de dados, agentes de dados, notebooks, pipelines) no mesmo espaço de trabalho para facilitar a promoção.
Teste as alterações do agente de dados no espaço de trabalho de teste antes de o promover para a produção.
Use mensagens de confirmação descritivas para facilitar a compreensão do histórico.
Não faça alterações diretamente na pasta publicada no repositório Git.
Use padrões de configuração independentes do ambiente (por exemplo, referências de ligação via Biblioteca de Variáveis quando suportado) para evitar codificar valores específicos do ambiente em configurações de fontes de dados de agentes de dados. Esta prática facilita fusões e implementações de branches mais fluidas ao longo do desenvolvimento, teste e produção.

Limitações e considerações

Somente espaços de trabalho conectados a um repositório Git podem usar recursos ALM baseados em Git.
As entidades de serviço são suportadas no agente de dados do Fabric apenas como parte de cenários ALM. Se você precisar interagir com um agente de dados fora dos fluxos de trabalho do ALM, a entidade de serviço não será suportada.
Os pipelines de implementação exigem que os espaços de trabalho tanto de origem como de destino estejam no mesmo tenant.
Um grande número de confirmações frequentes pode afetar o tamanho e o desempenho do repositório.

Comentários

Esta página foi útil?

Last updated on 2026-04-22