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

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

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

Importante

Este recurso está em pré-visualização.

Ao utilizar a integração do Git no Fabric, as equipas podem aplicar práticas modernas de controlo de versões ao desenvolvimento em armazém. Os programadores podem isolar alterações nos ramos, acompanhar a evolução do esquema através de commits, colaborar através de pull requests e sincronizar atualizações entre repositórios Git e espaços de trabalho Fabric.

Cenários típicos incluem:

  • Desenvolvimento seguro de alterações de esquema em ramos e espaços de trabalho
  • Versionamento de objetos de armazém no Git
  • Colaborar em múltiplos ramos e espaços de trabalho
  • Promoção de 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 fiabilidade ao longo dos ciclos de vida do desenvolvimento do armazém, é necessário compreender estes fluxos de trabalho.

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

Quando ligas um Fabric Data Warehouse workspace ao Git, comprometes definições de warehouse como um projeto de base de dados. Este projeto torna-se a representação autoritativa do esquema de armazém no controlo de versões e serve de base para as atividades de desenvolvimento em curso. No explorador de controlo de versão, o esquema aparece como ficheiros individuais .sql .

Captura de ecrã do esquema de um armazém no explorador de controlo de versão.

Ao usar Fabric Integração Git e Fabric Data Warehouse, pode:

Comparação

Durante este processo de sincronização, o Fabric utiliza implantação incremental de esquemas baseada em DacFx para aplicar alterações. Esta abordagem aplica-se apenas às diferenças de esquema relevantes 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 controlo de versão, manter diferenças de esquema mais limpas entre ramificações e suportar fluxos de trabalho eficientes de ramificação e fusão. Como o processo de extração é consciente do esquema, também permite uma comparação e validação fiáveis entre o estado do workspace e as definições Git-tracked.

Padronizar a forma 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 esquemas mantêm-se estáveis entre ramos, as diferenças refletem com maior precisão as mudanças intencionais de desenvolvimento, e o controlo de versões torna-se uma base fiável para implementação, colaboração e gestão do ciclo de vida.

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

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

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

  • Dependências entre itens entre armazéns e endpoints de análise SQL não são atualmente suportadas em fluxos de trabalho de desenvolvimento. Como resultado, cenários que dependem de alterações coordenadas entre estes itens podem não funcionar de forma fiável.

  • Os commits seletivos ao nível do armazém não são atualmente suportados. As alterações são feitas ao nível do item do armazém em vez de a níveis mais finos e granulares dos objetos.

  • O suporte de controlo de versões para endpoints de análise SQL não está atualmente disponível. Esta limitação pode restringir a gestão do ciclo de vida de ponta a ponta quando as soluções abrangem tanto armazéns como endpoints de análise SQL.

Limitações na integração com o Git

  • Quando dois ou mais itens de armazém se referenciam mutuamente, formam uma dependência cíclica. O sistema deteta esta referência circular durante operações de ramificação ou sincronização Git-to-workspace, fazendo com que estas operações falhem. Evite dependências cíclicas entre itens.
  • Atualmente, não cries um Dataflow Gen2 com destino de saída para o armazém. Um novo item com nome DataflowsStagingWarehouse aparece no repositório e bloqueia o commit e atualização a partir do Git.
  • Dependências entre itens, sequenciação de itens e lacunas de sincronização entre o endpoint de análise SQL e o data warehouse impactam os fluxos de trabalho de "ramificação para um novo ou existente espaço de trabalho" e "mudança para um ramo diferente" durante o desenvolvimento e integração contínua.
  • Se um objeto referenciar outro objeto no mesmo armazém usando a nomenclatura 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, consulte Referências aos próprios objetos do armazém usando um nome em três partes.
  • Se alterar uma coluna que tenha IDENTITY definido, fazer commit ou atualizar a partir do Git pode falhar até IDENTITY_INSERT estar ativado para a tabela.
  • Se o repositório contiver um .sqlproj ficheiro que fixa uma versão antiga Microsoft.Build.Sql do SDK, a confirmação ou atualização a partir do Git pode falhar porque o SDK mais antigo não reconhece sintaxe mais recente do armazém, como IDENTITY colunas e CLUSTER BY. Para mais informações e uma solução alternativa, consulte .sqlproj desatualizado no repositório Git.
  • Se um objeto referenciar duas ou mais tabelas noutro armazém 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 noutro armazém.
  • Se os seus scripts referenciarem dois ou mais objetos diferentes no mesmo esquema de outro warehouse e escreverem o nome do esquema com maiúsculas inconsistentes, o commit ou atualização a partir 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 na coluna com objetos candidatos duplicados.

Cenários não suportados

Os seguintes fluxos de trabalho de CI/CD não são oficialmente suportados quando armazéns de dados em diferentes áreas de trabalho possuem colações diferentes. Embora estas operações possam ter sucesso sem erros, podem resultar em erros de metadados.

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

Scenario Description Risco
Pipelines de implementação Promover conteúdo de data warehouse através de fases de pipeline (por exemplo, Desenvolvimento → Teste → Produção) onde o data warehouse alvo foi criado com uma colação diferente da fonte não é suportado. A implementação pode ter sucesso, mas a intercalação do conjunto de dados não é atualizada para alinhar à intercalação do armazém alvo.
Expandir-se para um espaço de trabalho novo ou existente Usar integração com o Git para expandir de um espaço de trabalho existente para um novo ou existente onde o armazém tem uma classificação diferente não é suportado. O conteúdo do armazém está sincronizado, mas os metadados de compilação não são reconciliados.
Mudança de ramificações num espaço de trabalho Mudar para um ramo associado a um repositório de uma ordenação diferente num espaço de trabalho conectado ao Git não é suportado. Conteúdos sincronizados podem transferir pressupostos de ordenação que não correspondem ao sistema de armazenamento atual.
Integração de alterações entre espaços de trabalho por meio de branches A fusão de branches Git entre espaços de trabalho onde os repositórios têm diferentes coleções não é suportada. A operação de fusão pode ser bem-sucedida no nível do Git, mas a organização resultante do conjunto de dados não reflete a organização do depósito-alvo.

Passo seguinte

Use a Integração Git para desenvolvimento e implementação de armazém

Conteúdo relacionado

  • Last updated on