Controlo de código-fonte (pré-visualização)

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

Este artigo explica como funcionam os pipelines de integração e implementação do Git para armazéns no Microsoft Fabric. Saiba como configurar uma conexão com seu repositório, gerenciar seus armazéns e implantá-los em diferentes ambientes. O controlo de código-fonte para o Fabric Warehouse é atualmente uma funcionalidade em versão de pré-visualização.

Você pode usar tanto a integração com o Git quanto os pipelines de implantação para diferentes cenários.

  • Utilize projetos de bases de dados Git e SQL para gerir alterações incrementais, colaboração em equipa e histórico de commits em objetos individuais da base de dados.
  • Use pipelines de implantação para promover alterações de código em diferentes ambientes de pré-produção e produção.

Integração no Git

A integração do Git no Microsoft Fabric permite aos programadores integrar diretamente os seus processos de desenvolvimento, ferramentas e melhores práticas na plataforma Fabric. Permite que os programadores que desenvolvem em Fabric possam:

  • Fazer backup e versionar o seu trabalho
  • Reverter para estágios anteriores conforme necessário
  • Colabore com outros ou trabalhe sozinho usando branches Git
  • Aplique as capacidades das ferramentas de controlo de código fonte familiares para gerir os itens Fabric.

Para obter mais informações sobre o processo de integração do Git, consulte:

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

Na página Configurações do espaço de trabalho , você pode facilmente configurar uma conexão com seu repositório para confirmar e sincronizar alterações.

  1. Para configurar a conexão, consulte Introdução à integração com o Git. Siga as instruções para Ligar a um repositório Git para Azure DevOps ou GitHub como fornecedor Git.
  2. Uma vez conectados, os seus itens, incluindo armazéns, aparecem no controlo de origem. Captura de ecrã do portal Fabric do armazém nas definições de controlo de origem.
  3. Depois de conectar com êxito as instâncias de depósito ao repositório Git, você verá a estrutura de pastas do depósito no repositório. Agora você pode executar operações futuras, como a criação de uma solicitação pull.

Projetos de banco de dados para um armazém no Git

A imagem a seguir é um exemplo da estrutura de ficheiros de cada item de armazém no repositório.

Captura de ecrã do portal Fabric de um esquema de armazém de exemplo.

Quando você compromete o item de repositório no repositório do Git, o armazém é convertido para um formato de código-fonte, como um projeto de banco de dados SQL. Um projeto SQL é uma representação local de objetos SQL que compõem o esquema para um único banco de dados, como tabelas, procedimentos armazenados ou funções. A estrutura de pastas dos objetos de banco de dados é organizada por Schema/Object Type. Cada objeto no armazém é representado com um arquivo .sql que contém sua definição de linguagem de definição de dados (DDL). Os dados de tabelas de armazém e as funcionalidades de segurança SQL não estão incluídos no projeto de base de dados SQL.

As consultas partilhadas também são confirmadas no repositório e herdam o nome como foram salvas.

Pipeline de deployment

Você também pode usar pipelines de implantação para implantar o código do seu data warehouse em diferentes ambientes, como desenvolvimento, teste e produção. Os pipelines de implantação não revelam nenhum projeto de base de dados.

Utilize os seguintes passos para concluir a implantação do seu armazém, utilizando o pipeline de implementação.

  1. Crie um novo pipeline de implantação ou abra um pipeline de implantação existente. Para obter mais informações, consulte Comece com os pipelines de implantação.
  2. Atribua espaços de trabalho a diferentes estágios de acordo com suas metas de implantação.
  3. Selecione, veja e compare itens, incluindo armazéns, entre diferentes fases, como mostrado no exemplo seguinte. Captura de ecrã do portal Fabric das fases de Desenvolvimento, Teste e Produção.
  4. Selecione Implantar para implantar seus armazéns nos estágios de desenvolvimento, teste e produção .

Para mais informações sobre o processo dos pipelines de implementação do Fabric, consulte Introdução aos pipelines de implementação.

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

  • Deve exportar ou migrar funcionalidades de segurança SQL utilizando uma abordagem baseada em scripts. Considere usar um script pós-implementação num projeto de base de dados SQL. Pode configurar este script abrindo o projeto com a extensão SQL Database Projects disponível em Visual Studio Code.

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

  • Atualmente, se usar ALTER TABLE para adicionar uma restrição ou coluna no projeto da base de dados, o processo de desdobramento remove e recria a tabela, o que resulta em perda de dados. Para preservar a definição da tabela e os dados, considere a seguinte solução alternativa:
    • Crie uma nova cópia da tabela no armazém usando CREATE TABLE e INSERT, CREATE TABLE AS SELECT, ou Clone table.
    • Modificar a nova definição da tabela com novas restrições ou colunas, conforme desejado, usando ALTER TABLE.
    • Exclua a tabela antiga.
    • Renomeie a nova tabela para o nome da tabela antiga usando sp_rename.
    • Modifique a definição da tabela antiga no projeto de banco de dados SQL exatamente da mesma maneira. O projeto de banco de dados SQL do depósito no controle do código-fonte e o armazém dinâmico agora devem corresponder.
  • 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.
  • A integração do Fabric Git não suporta o item do endpoint de análise SQL.
  • 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.

Limitações dos pipelines de implantação

  • Atualmente, se usar ALTER TABLE para adicionar uma restrição ou coluna no projeto da base de dados, o processo de desdobramento remove e recria a tabela, o que resulta em perda de dados.
  • Atualmente, não cries um Dataflow Gen2 com destino de saída para o armazém. Um novo item nomeado DataflowsStagingWarehouse aparece no pipeline de implementação e bloqueia a implementação.
  • Os pipelines de implementação do Fabric não suportam o item endpoint de análise SQL.
  • Dependências entre itens, sequenciação de itens e lacunas de sincronização entre o endpoint de análise SQL e o armazém impactam os fluxos de trabalho do Fabric Deployment Pipelines.

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 Descrição 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.