Exemplos de planos de implementação (pré-visualização)

Este artigo mostra os padrões para os quais os planos de implantação são frequentemente utilizados. Cada um descreve os grupos de implementação e as ações a eles associadas, para que possas construir o equivalente na tela.

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

Implementar um item que dependa de dados que outro item produz

Esta é a razão mais comum para usar um plano.

O espaço de trabalho

Uma equipa de vendas mantém a sua solução de análise num único espaço de trabalho ligado ao git, que contém quatro itens:

Item	Tipo	O que faz
`Sales_Lakehouse`	Lakehouse	Guarda as tabelas de vendas. Está vazio quando é implementado, porque uma implementação copia definições de itens, não dados.
`Hydrate_TopCustomers`	Computador portátil	Escreve as linhas de fonte bruta na casa do lago.
`Publish_TopCustomers`	Computador portátil	Transforma essas linhas na tabela publicada `dbo.top_customers` .
`Sales_Warehouse`	Armazém	Mantém a vista `dbo.vw_top_customers`, que diz `dbo.top_customers`.

Porque a ordem de implementação, por si só, não é suficiente

O Fabric usa a linhagem dos itens para detetar que a vista do armazém faz referência a uma mesa da casa do lago, por isso coloca a casa do lago antes do armazém.

O Lineage não mostra que a tabela tem de ser preenchida antes de a visualização ser válida. A tabela não aparece com a definição do item. Os dois cadernos produzem-no em tempo de execução:

Implemente este espaço de trabalho sem um plano e a implementação falha. Cada item é copiado corretamente, mas a vista do armazém é criada contra uma tabela que ninguém produziu ainda, e a implementação reporta que o nome do objeto é inválido. O alvo fica parcialmente posicionado.

Não há nada de errado com os objetos. O que falta é a instrução para executar os notebooks entre a implementação do lakehouse e a implementação do warehouse. 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 armazém. O grupo do lakehouse executa os dois notebooks como ações pós-implementação:

Grupo de implementação	Item implementado	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 (armazém)	None	Sales_Lakehouse

Depois de o lakehouse ser implementado, Hydrate_TopCustomers escreve 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 apenas depois de ambas as ações terminarem. O Fabric pode então implantar o armazém e criar a sua visualização.

Os cadernos são ações do grupo da casa do lago, 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:

Compreenda a estrutura plan.yml

Constróis um plano na tela. Quando o espaço de trabalho está ligado ao Git, o plano é armazenado como um plan.yml ficheiro na pasta do item do plano de implementação, por isso é revisto 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 ficheiro 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 no plano.
`name`	Dá a um grupo ou ação um nome único que as dependências podem referenciar.
`logicalId`	Identifica o item Fabric em vários espaços de trabalho.
`dependsOn`	Declara dependências de outro grupo ou ação por nome.
`preActions` e `postActions`	Execute tarefas suportadas antes ou depois de o item do grupo ser colocado em produção.
`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 nesta definição:

Um grupo nomeia um item. logicalId é o ID lógico do item, o mesmo identificador usado pela integração do Git, pelo que o plano mantém-se válido à medida que o item se move entre espaços de trabalho.
A ordem do grupo é expressa com dependsOn, e não pela posição no ficheiro. Reordenar os grupos no ficheiro não muda nada.
A ordem de ação também é expressa com dependsOn. Run Publish_TopCustomers começa apenas depois de Run Hydrate_TopCustomers terminar.
postActions é executado após o item do grupo ser implementado. Use preActions para trabalhos que tenham de acontecer primeiro, como uma verificação de validação.

Sugestão

Uma ação termina quando a execução do item termina, não quando os serviços a jusante recuperam. Neste exemplo, a última célula de Publish_TopCustomers aguarda até que o endpoint de análise SQL do lakehouse tenha catalogado a nova tabela. Coloca esse tipo de teste de prontidão na ação, porque o plano não espera por ti.

Atualize o conteúdo após a sua implementação

Uma implementação atualiza as definições dos itens. Não executa nada, por isso um modelo semântico ou um relatório reflete a nova definição mas não os novos dados.

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

Anexe este plano a uma implementação de pipeline de implantação para que a promoção para uma fase deixe o alvo pronto a usar, em vez de precisar de uma atualização manual.

Valide antes de qualquer coisa ser implementada

Uma ação pré-deploy é executada antes do item do seu grupo ser implementado, por isso podes usar um como portal.

Uma ação só pode executar um item já implementado, por isso a verificação em si é implementada por um grupo anterior:

Grupo de implementação	Item implementado	É executado antes de o item ser implementado	Depende de
Pré-voo	Preflight_Checks (bloco de notas)	None	Nada
First_Real_Item	O primeiro item do lançamento	Executar Preflight_Checks	Pré-voo

Se a verificação falhar, a implantação para e nada do que depende desse grupo é implantado. Use isto para confirmar que as ligações se resolvem, que uma capacidade necessária está a funcionar ou que um sistema de origem está disponível antes do início do lançamento.

Note

Uma ação de pré-implementação não pode executar o item que o respetivo grupo implementa, porque esse item ainda não existe no destino. Implemente o item que realiza a verificação num grupo anterior, como mostrado aqui.

Encomenda trabalhos que a linhagem não consegue ver

Dois itens podem ser completamente independentes no que diz respeito à linhagem e ainda precisam de uma ordem. Um plano é como se expressa isso.

Grupo de implementação	Item implementado	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 através de uma ligação em vez de uma referência direta	Dados_de_referência

Como a dependência passa por uma ligaçã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 a 2026-09-29