Exemplos de planos de implantação (prévia)

Este artigo mostra padrões para os quais planos de implantação são comumente usados. Cada um descreve os grupos de implantação e as ações associadas a eles, para que você possa construir o equivalente na tela.

Para como construir um plano, veja Criar um plano de implantação.

Implante um item que dependa de dados que outro item produz

Esse é o motivo mais comum para usar um plano.

O espaço de trabalho

Uma equipe de vendas mantém sua solução de análise em um único espaço de trabalho conectado ao git, que contém quatro itens:

Item	Tipo	O que faz
`Sales_Lakehouse`	Lakehouse	Armazena as tabelas de vendas. Ele fica vazio quando é implantado, porque uma implantação copia definições de itens, não dados.
`Hydrate_TopCustomers`	Notebook	Escreve as fileiras de fonte bruta na casa do lago.
`Publish_TopCustomers`	Notebook	Transforma essas linhas na tabela publicada `dbo.top_customers` .
`Sales_Warehouse`	Armazém	Mantém a exibição `dbo.vw_top_customers`, que mostra `dbo.top_customers`.

Por que só a ordem de implantação não é suficiente

O Fabric usa a linhagem dos itens para detectar que a visualização do depósito faz referência a uma mesa da casa do lago, então ele implanta a casa do lago antes do depósito.

O Lineage não mostra que a tabela precisa ser preenchida antes que a visualização seja válida. A tabela não vem com a definição do item. Os dois notebooks produzem isso em tempo de execução:

Implante esse espaço de trabalho sem um plano e a implantação falha. Cada item é copiado corretamente, mas a visão do data warehouse é criada com base em uma tabela que ainda não foi criada, e a implantação informa que o nome do objeto é inválido. O alvo fica parcialmente posicionado.

Não há nada errado com os itens. O que falta é a instrução para rodar os notebooks entre a implantação da casa do lago e a implantação do depósito. Essa instrução é o plano.

O plano

O plano tem dois grupos de implantação, um para a casa do lago e outro para o depósito. O grupo lakehouse executa ambos os cadernos como ações pós-implantação:

Grupo de implantação	Item implantado	Ações pós-implantação	Depende de
Sales_Lakehouse	Sales_Lakehouse (casa do lago)	1. Executar Hydrate_TopCustomers 2. Execute Publish_TopCustomers	Nada
Vendas_Armazém	Sales_Warehouse (depósito)	None	Sales_Lakehouse

Após a implantação do lakehouse, Hydrate_TopCustomers grava as linhas de origem. Depois Publish_TopCustomers , cria dbo.top_customers e espera até que o endpoint de análise SQL exponha a tabela. O grupo da casa do lago termina somente após ambas as ações terminarem. O Fabric pode então implantar o depósito e criar sua visualização.

Os cadernos são ações no grupo lakehouse, não grupos de implantação separados. Publish_TopCustomers Depende de Hydrate_TopCustomers, e o grupo do armazém depende do grupo Lakehouse concluído.

Aqui está o mesmo plano na tela:

Entenda a estrutura plan.yml

Você constrói um plano na tela. Quando o workspace está conectado ao Git, o plano é armazenado como um plan.yml arquivo na pasta do item do plano de implantação, então ele é revisado e versionado como qualquer outro item:

$schema: https://developer.microsoft.com/json-schemas/fabric/item/deploymentPlan/definition/plan/1.0.0/schema.json
version: 1.0.0
groups:
  - name: Sales_Lakehouse
    logicalId: 11111111-1111-1111-1111-111111111111
    postActions:
      - name: Run Hydrate_TopCustomers
        job:
          type: Execute
          logicalId: 22222222-2222-2222-2222-222222222222
      - name: Run Publish_TopCustomers
        dependsOn:
          - actionName: Run Hydrate_TopCustomers
        job:
          type: Execute
          logicalId: 33333333-3333-3333-3333-333333333333
  - name: Sales_Warehouse
    logicalId: 44444444-4444-4444-4444-444444444444
    dependsOn:
      - groupName: Sales_Lakehouse

O arquivo tem a seguinte estrutura:

Elemento	Purpose
`$schema`	Identifica o esquema que valida a definição do plano.
`version`	Identifica a versão de definição do plano.
`groups`	Contém os grupos de implantação do plano.
`name`	Dá a um grupo ou ação um nome único que dependências podem referenciar.
`logicalId`	Identifica o item do Fabric em todos os espaços de trabalho.
`dependsOn`	Declara dependências de outro grupo ou de outra ação por nome.
`preActions` e `postActions`	Executar jobs compatíveis antes ou depois da implantação do item do grupo.
`job`	Identifica o tipo de trabalho, o ID lógico do item e os parâmetros opcionais para uma ação.

Algumas coisas a notar nessa definição:

Um grupo nomeia um item. logicalId é o ID lógico do item, o mesmo identificador usado pela integração do Git, então o plano permanece válido enquanto o item se move entre os espaços de trabalho.
A ordem do grupo é expressa com dependsOn, e não pela posição no arquivo. Reorganizar os grupos no arquivo não muda nada.
A ordem de ação também é expressa com dependsOn. Run Publish_TopCustomers começa apenas após Run Hydrate_TopCustomers terminar.
postActions Executar depois que o item do grupo for implantado. Use preActions para trabalhos que precisam acontecer primeiro, como uma verificação de validação.

Dica

Uma ação é finalizada quando a execução do item termina, não quando os serviços downstream ficam em dia. Neste exemplo, a última célula de Publish_TopCustomers espera até que o endpoint de análise SQL do Lakehouse tenha catalogado a nova tabela. Coloque esse tipo de teste de prontidão na ação, porque o plano não espera por você.

Atualize o conteúdo após a implantação

Uma implantação atualiza as definições dos itens. Ele não roda nada, então um modelo semântico ou um relatório reflete a nova definição, mas não novos dados.

Grupo de implantação	Item implantado	Executa após o item ser implantado	Depende de
Vendas_Armazém	Sales_Warehouse (depósito)	None	Nada
Sales_Model	Sales_Model (modelo semântico)	Execute um pipeline de dados que atualize o modelo	Vendas_Armazém

Anexe esse plano a uma implantação do pipeline de implantação para que a promoção para um estágio deixe o alvo pronto para uso, em vez de precisar de uma atualização manual.

Valide antes de qualquer implantação

Uma ação de pré-implantação é executada antes de o item do grupo ser implantado, portanto você pode usá-la como um bloqueio.

Uma ação só pode executar um item que já foi implantado, então a verificação em si é implantada por um grupo anterior:

Grupo de implantação	Item implantado	É executado antes de o item ser implantado	Depende de
Pré-voo	Preflight_Checks (notebook)	None	Nada
First_Real_Item	O primeiro item do lançamento	Corra Preflight_Checks	Pré-voo

Se a verificação falhar, a implantação é interrompida e nada que dependa desse grupo é implantado. Use isso para confirmar se as conexões se resolvem, se uma capacidade necessária está em execução ou se um sistema fonte está disponível antes do início da liberação.

Note

Uma ação pré-implantação não pode rodar o item que seu próprio grupo implanta, porque esse item ainda não existe no alvo. Implante o item que realiza a verificação em um grupo anterior, como mostrado aqui.

Classificar trabalhos que o lineage não consegue ver

Dois itens podem ser completamente independentes em termos de linhagem, e ainda precisam de uma ordem. Um plano é como você expressa isso.

Grupo de implantação	Item implantado	Depende de
Dados_de_Referência	O item que produz dados de referência	Nada
Domain_Item	Um item que lê dados de referência por meio de uma conexão em vez de uma referência direta	Dados de referência

Como a dependência passa por uma conexão em vez de uma referência de item, o Fabric não consegue inferir isso. O plano fornece a ordem.

Comentários

Esta página foi útil?

Última atualização em 2026-09-29