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:

  • Desenvolver alterações de esquema de forma segura em ramificações 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.

Ao ligar uma área de trabalho do Fabric Data Warehouse ao Git, consolida as definições do armazém de dados como um projeto de base de dados. Este projeto torna-se a representação de referência do esquema do armazém de dados no controlo de código-fonte e serve de base às atividades contínuas de desenvolvimento. 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 a Integração do Git no Fabric e o 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 alterações desnecessárias no controlo de código-fonte, a manter diferenças entre esquemas mais limpas entre ramos e a suportar fluxos de trabalho eficientes de criação de ramos e fusão. Como o processo de extração tem em conta o esquema, também permite comparar e validar de forma fiável o estado da área de trabalho e as definições controladas pelo Git.

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 esquema mantêm-se estáveis entre ramos, as diferenças refletem com maior precisão alterações intencionais no desenvolvimento e o controlo de código-fonte torna-se uma base fiável para implantaçã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 baseada em scripts para exportação e migração. Considere usar um script pós-implementação num projeto de base de dados SQL. Pode configurar um script pós-implementação no projeto com a extensão SQL Database Projects disponível no Visual Studio Code.

  • 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.

  • Scripts de pré-implementação ou pós-implementação e configurações adicionais de publicação adicionados diretamente ao projeto de base de dados via Git não são preservados nos fluxos de trabalho de desenvolvimento. Pode ser necessário gerir estas configurações separadamente, fora do espaço de trabalho do Fabric.

  • As confirmações seletivas ao nível de armazém não são atualmente suportadas. 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 criação de ramificações ou de sincronização do Git para a área de trabalho, o que faz 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 data warehouse, utilizando a nomeação em três partes (database.schema.object), a confirmação ou atualização desde o Git pode falhar. Para mais informações e uma forma de contornar o problema, consulte Referências aos objetos do próprio armazém utilizando um nome em três partes.
  • Se alterar uma coluna que tenha IDENTITY definido, efetuar commit ou atualizar a partir do Git pode falhar até que IDENTITY_INSERT seja ativado na tabela.
  • Se o repositório contiver um ficheiro .sqlproj que fixa uma versão mais antiga do SDK Microsoft.Build.Sql, fazer commit ou atualizar a partir do Git pode falhar, porque o SDK mais antigo não reconhece sintaxe mais recente do armazém de dados, como colunas IDENTITY e CLUSTER BY. Para mais informações e uma solução alternativa, consulte .sqlproj desatualizado no repositório Git.
  • Se um objeto fizer referência a duas ou mais tabelas noutro armazém sem qualificar cada coluna com um alias, o commit ou a atualização a partir do Git podem 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 fizerem referência a dois ou mais objetos diferentes no mesmo esquema de outro armazém de dados e escreverem o nome do esquema com uma utilização inconsistente de maiúsculas e minúsculas, ao efetuar um commit ou uma atualização a partir do Git, a operação pode falhar. Para mais informações e uma solução alternativa, veja Capitalização inconsistente dos nomes dos esquemas.
  • Podem ocorrer erros de coluna ambígua cuja lista de candidatos contém um separador :: ao submeter ou atualizar a partir do Git, mesmo quando não existe ambiguidade real. 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

  • Última atualização a