Integração com Git para desenvolvimento de armazéns de Fabric

Aplica-se a: ✅ Armazém no Microsoft Fabric

Este artigo explica as vantagens de desenvolver e implantar Fabric Data Warehouse com a integração integrada do Git da Fabric.

Importante

Esse recurso está na versão prévia.

Ao usar a integração do Git no Fabric, as equipes podem aplicar práticas modernas de controle de versão ao desenvolvimento de warehouses. Desenvolvedores podem isolar mudanças nos ramos, acompanhar a evolução do esquema por meio de commits, colaborar por meio de pull requests e sincronizar atualizações entre repositórios Git e espaços de trabalho do Fabric.

Os cenários comuns são:

  • Desenvolvimento de mudanças de esquema com segurança em ramificações e espaços de trabalho
  • Versionamento de objetos do warehouse no Git
  • Colaborando entre múltiplos ramos e espaços de trabalho
  • Promovendo mudanças validadas entre filiais
  • Manter os itens do espaço de trabalho (armazém e outros) alinhados com a fonte de verdade do Git

Para manter consistência, rastreabilidade e confiabilidade ao longo dos ciclos de vida do desenvolvimento do armazém, é necessário entender esses fluxos de trabalho.

Diagrama do ciclo de vida de desenvolvimento da integração do Git do Fabric Warehouse.

Quando você conecta um Fabric Data Warehouse workspace ao Git, você faz commit das definições do warehouse como um projeto de banco de dados. Este projeto se torna a representação autoritativa do esquema de armazenamento no controle de versão e serve como base para as atividades de desenvolvimento contínuas. No explorador de controle de versão, o esquema aparece como arquivos individuais .sql .

Captura de tela do esquema de um warehouse no explorador de controle de versão.

Usando Fabric Integração Git e Fabric Data Warehouse, você pode:

Comparação

Durante esse processo de sincronização, o Fabric utiliza implantação incremental de esquema baseada em DacFx para aplicar alterações. Essa abordagem aplica apenas as diferenças relevantes de esquema ao armazém, em vez de atualizar toda a definição do armazém.

A extração incremental ajuda a reduzir o churn desnecessário no controle de versão, manter diferenças de esquema mais limpas entre os ramos e apoiar fluxos de trabalho eficientes de ramificação e fusão. Como o processo de extração é consciente do esquema, ele também permite uma comparação e validação confiáveis entre o estado do workspace e as definições rastreadas por Git.

Padronizar como os esquemas de armazém são extraídos e armazenados melhora a consistência entre os ambientes de desenvolvimento. As definições de esquema permanecem estáveis entre os ramos, as diferenças refletem com mais precisão mudanças intencionais de desenvolvimento, e o controle de versão torna-se uma base confiável para implantação, colaboração e gerenciamento do ciclo de vida.

O XMLA.json arquivo em si é excluído durante os fluxos de trabalho de integração do Git. O Fabric exclui esse arquivo de commits e atualizações para que os metadados semânticos model padrão não sejam armazenados acidentalmente no Git. Ao sincronizar um espaço de trabalho do Git, isso XMLA.json é ignorado, o que ajuda a evitar conflitos, sobrcritas não intencionais e ruído durante troca de branch ou atualizações do Git.

Limitações no controle do código-fonte

Recursos de segurança SQL, como permissões, exigem uma abordagem separada de exportação e migração.

  • Dependências entre itens entre warehouses e endpoints de análise SQL atualmente não são suportadas em fluxos de trabalho de desenvolvimento. Como resultado, cenários que dependem de mudanças coordenadas entre esses itens podem não funcionar de forma confiável.

  • Commits seletivos no nível do depósito atualmente não são suportados. As mudanças são feitas no nível do item do armazém, em vez de em níveis mais finos e granulares de objetos.

  • O suporte ao controle de versões para endpoints de análise SQL não está disponível no momento. Essa limitação pode restringir o gerenciamento do ciclo de vida de ponta a ponta quando as soluções abrangem tanto warehouses quanto endpoints de análise SQL.

Limitações na integração do Git

  • Quando dois ou mais itens de armazém se referenciam, eles formam uma dependência cíclica. O sistema detecta essa referência circular durante operações de ramificação ou sincronização do Git-to-workspace, causando a falha dessas operações. Evite dependências cíclicas entre os itens.
  • Atualmente, não crie um Dataflow Gen2 com um destino de saída para o armazém. Um novo item nomeado DataflowsStagingWarehouse aparece no repositório e bloqueia a confirmação e a atualização do Git.
  • Dependências cruzadas entre itens, sequência de itens e falhas de sincronização entre o endpoint de análise SQL e o data warehouse impactam os fluxos de trabalho "criando um branch para um workspace novo ou existente" e "mudando para um branch diferente" durante o desenvolvimento e a integração contínua.
  • Se um objeto referenciar outro objeto no mesmo warehouse usando nomes em três partes (database.schema.object), o commit ou atualização a partir do Git pode falhar. Para mais informações e uma solução alternativa, veja Referências aos próprios objetos do depósito usando um nome em três partes.
  • Se você mudar uma coluna que definiu IDENTITY , fazer commit ou atualizar a partir do Git pode falhar até IDENTITY_INSERT que seja ativado para a tabela.
  • Se o repositório contiver um .sqlproj arquivo que fixa uma versão antiga Microsoft.Build.Sql do SDK, o commit ou atualização a partir do Git pode falhar porque o SDK mais antigo não reconhece sintaxe mais recente do warehouse, como IDENTITY colunas e CLUSTER BY. Para mais informações e uma solução alternativa, veja .sqlproj desatualizado no repositório Git.
  • Se um objeto referenciar duas ou mais tabelas em outro warehouse sem qualificar o alias em cada coluna, o commit ou atualização a partir do Git pode falhar. Para mais informações e uma solução alternativa, veja Colunas Não Qualificadas em objetos que referenciam duas ou mais tabelas em outro depósito.
  • Se seus scripts referenciam dois ou mais objetos diferentes no mesmo esquema de outro warehouse e escrevem o nome do esquema com maiúsculas inconsistentes, o commit ou atualização do Git pode falhar. Para mais informações e uma solução alternativa, veja Capitalização inconsistente dos nomes dos esquemas.
  • Erros ambíguos de coluna cuja lista de candidatos contém um :: separador podem ocorrer ao fazer commit ou atualizar a partir do Git, mesmo quando não há ambiguidade genuína. Para mais informações e soluções alternativas, veja Erros ambíguos de coluna com objetos candidatos duplicados.

Cenários sem suporte

Os fluxos de trabalho de CI/CD a seguir não têm suporte oficial quando os repositórios em diferentes espaços de trabalho possuem ordenações distintas. Embora essas operações possam ter êxito sem erros, elas podem resultar em erros de metadados.

Em todos esses cenários, se ocorrer uma incompatibilidade de ordenação, use o script em Python scripts/dw-collation-error-update-tmsl/pbi_interactive.py no repositório do GitHub da caixa de ferramentas do Fabric para atualizar a ordenação do conjunto de dados (TMSL) para corresponder à ordenação do armazém de dados.

Scenario Description Risco
Pipelines de implantação Promover o conteúdo do depósito por meio de estágios de pipeline (por exemplo, Dev → Test → Prod), em que o depósito de destino foi criado com uma ordenação diferente da origem, não é suportado. A implantação pode ter êxito, mas a ordenação do conjunto de dados não é atualizada para corresponder à do armazém de dados de destino.
Acessando um ambiente de trabalho novo ou existente Não há suporte para usar a integração do Git para ramificar de um workspace existente para um workspace novo ou existente em que o armazém tenha uma ordenação diferente. O conteúdo do warehouse é sincronizado, mas os metadados de ordenação não são reconciliados.
Alternar ramificações em um espaço de trabalho Não há suporte para alternar para uma ramificação associada a um warehouse de uma ordenação diferente em um workspace conectado ao Git. O conteúdo sincronizado pode carregar suposições de ordenação que não correspondem ao armazém atual.
Mesclando alterações entre espaços de trabalho por meio de ramificações Não há suporte para a mesclagem de branches do Git entre workspaces em que os repositórios têm intercalações diferentes. A mesclagem pode ter êxito no nível do Git, mas a ordenação do conjunto de dados resultante não reflete a ordenação do armazém de dados de destino.

Próxima etapa

Use a integração do Git para desenvolvimento e implantação de armazéns

Conteúdo relacionado

  • Last updated on