Compartilhar via

O que é a integração do Git do Microsoft Fabric?

  • Artigo

Este artigo explica aos desenvolvedores como integrar o controle de versão do Git à ferramenta ALM (Gerenciamento do Ciclo de Vida do Aplicativo) do Microsoft Fabric.

Observação

Alguns dos itens para integração do Git estão em versão prévia. Para obter mais informações, confira a lista de itens com suporte.

A integração do Git ao Microsoft Fabric permite que os desenvolvedores integrem seus processos de desenvolvimento, ferramentas e práticas recomendadas diretamente na plataforma do Fabric. Ela permite que os desenvolvedores que estão desenvolvendo no Fabric:

  • Façam backup e versionem seu trabalho
  • Reverter para fases anteriores, conforme necessário
  • Colaborem com outras pessoas ou trabalhem sozinhos usando branches do Git
  • Aplique os recursos de ferramentas familiares de controle do código-fonte para gerenciar itens do Fabric

Consulte a lista de itens com suporte .

Informações de privacidade

Antes de você habilitar a integração do Git, certifique-se de revisar as seguintes políticas de privacidade:

Provedores Git com suporte

Os seguintes provedores Git são compatíveis:

Itens com suporte

Os itens a seguir têm suporte atualmente:

Se o espaço de trabalho ou o diretório do Git tiver itens sem suporte, ele ainda poderá ser conectado, mas os itens sem suporte serão ignorados. Eles não são salvos ou sincronizados, mas também não são excluídos. Eles aparecem no painel de controle do código-fonte, mas você não pode realizar o commit deles e nem atualizá-los.

Considerações e limitações

Limitações gerais da integração do Git

  • O método de autenticação no Fabric deve ser pelo menos tão forte quanto o método de autenticação do Git. Por exemplo, se o Git exigir autenticação multifator, o Fabric também precisará exigir autenticação multifator.
  • No momento, não há suporte para os conjuntos de dados do Power BI conectados ao Analysis Services.
  • Espaços de trabalho com aplicativos de modelo instalados não podem ser conectados ao Git.
  • Não há suporte para submódulos.
  • Não há suporte para nuvens soberanas.

Limitações do GitHub Enterprise

Algumas configurações do GitHub Enterprise não são compatíveis. Por exemplo:

  • Lista de IPs permitidos

Limitações do workspace

  • Somente o administrador do espaço de trabalho pode gerenciar as conexões com o repositório do Git, como conectar, desconectar ou adicionar uma ramificação.
    Uma vez conectado, qualquer pessoa com permissão pode trabalhar no espaço de trabalho.

Limitações de branch e pasta

  • O nome do branch pode ter, no máximo, 244 caracteres.
  • O caminho completo de nomes de arquivo pode ter no máximo 250 caracteres. Nomes mais longos geram falhas.
  • O arquivo pode ter no máximo 25 MB.
  • A estrutura de pastas é mantida em até 10 níveis de profundidade.
  • Não é possível baixar um relatório/conjunto de dados como .pbix do serviço após implantá-los com integração com o Git.
  • Se o nome de exibição do item tiver qualquer uma dessas características, a pasta Git será renomeada para a ID lógica (Guid) e digite:
  • Ao conectar um workspace que tenha pastas ao Git, você precisará confirmar alterações no repositório Git se essa estrutura de pastas for diferente.

Limitações de nome de diretório

  • O nome do diretório que se conecta ao repositório Git tem as seguintes restrições de nomenclatura:

    • O nome do diretório não pode começar ou terminar com um espaço ou um tab.
    • O nome do diretório não pode conter nenhum dos seguintes caracteres: "/:<>\*?|

  • A pasta do item (a pasta que contém os arquivos de item) não pode conter nenhum dos seguintes caracteres: ":<>\*?|. Se você renomear a pasta para algo que inclua um desses caracteres, o Git não poderá se conectar ou sincronizar com o workspace e ocorrerá um erro.

Limitações de expansão

  • A ramificação requer permissões listadas na tabela de permissões.
  • É necessário haver uma capacidade disponível para essa ação.
  • Todas as limitações de nomenclatura de workspace e branch se aplicam ao criar um novo workspace.
  • Somente os itens com suporte do Git estão disponíveis no novo espaço de trabalho.
  • A lista de filiais relacionadas mostra apenas filiais e espaços de trabalho que você tem permissão para exibir.
  • A integração do Git deve estar habilitada.
  • Ao ramificar para fora, um novo branch é criado e as configurações do branch original não são copiadas. Ajuste as configurações ou definições para garantir que o novo atenda às políticas da sua organização.
  • Ao ramificar para um espaço de trabalho existente:
    • O workspace de destino deve dar suporte a uma conexão Git.
    • O usuário deve ser um administrador do workspace de destino.
    • O espaço de trabalho de destino deve ter capacidade.
    • O espaço de trabalho não pode ter aplicativos modelo.
  • Observe que, quando você ramifica para um espaço de trabalho, todos os itens que não são salvos no Git podem ser perdidos. Recomendamos que você faça o commit todos os itens que deseja manter antes de fazer o branch.

Limitações da sincronização e do commit

  • Você só pode sincronizar em uma direção por vez. Você não pode confirmar e atualizar ao mesmo tempo.
  • Não há suporte para rótulos de confidencialidade e a exportação de itens com rótulos de confidencialidade pode estar desabilitada. Para fazer commit de itens que têm rótulos de confidencialidade sem o rótulo de confidencialidade, peça ajuda ao administrador.
  • Funciona com itens limitados. Itens não compatíveis na pasta serão ignorados.
  • Nomes duplicados não são permitidos. Mesmo se o Power BI permitir a duplicação de nomes, a ação de atualizar, confirmar ou desfazer falhará.
  • Não há suporte para B2B.
  • A resolução de conflitos é realizada parcialmente no Git.
  • Durante o processo de Confirmar para o Git, o serviço do Fabric exclui todos os arquivos dentro da pasta do item que não fazem parte da definição do item. Arquivos não relacionados que não estejam em uma pasta de item não serão excluídos.
  • Após confirmar as alterações, você poderá notar algumas mudanças inesperadas no item que não foram feitas por você. Essas alterações são semanticamente insignificantes e podem ocorrer por vários motivos. Por exemplo:
    • Alteração manual do arquivo de definição do item. Essas alterações são válidas, mas podem ser diferentes daquelas feitas por meio dos editores. Por exemplo, se você renomear uma coluna do modelo semântico no Git e importar essa alteração para o espaço de trabalho, na próxima vez que confirmar as alterações no modelo semântico, o arquivo bim será registrado como alterado e a coluna modificada será enviada para o final da matriz columns. Isso ocorre porque o mecanismo AS que gera os arquivos bim envia as colunas renomeadas para o final da matriz. Essa alteração não afeta a forma como o item funciona.
    • Commits de um arquivo que usa as quebras de linha CRLF. O serviço utiliza as quebras de linha LF (avanço de linha). Se você tiver arquivos no repositório Git com quebras de linha CRLF, quando você fizer o commit a partir do serviço, esses arquivos serão alterados para LF. Por exemplo, se você abrir um relatório na área de trabalho, salve o arquivo de projeto (.pbip) e carregue-o no Git usando CRLF.
  • Atualizar um modelo semântico usando a API de Atualização Aprimorada causa um diff do Git após cada atualização.

Conteúdo relacionado