Perguntas frequentes sobre as ferramentas de gerenciamento do ciclo de vida Fabric

O gerenciamento do ciclo de vida tem duas partes: integração e implantação. Para entender o que é integração em Fabric, consulte a visão geral da integração do Git. Para entender o que são os pipelines de implantação no Fabric, consulte a visão geral dos pipelines de implantação.

Para obter uma breve explicação da integração do Git, consulte a Visão geral da integração do Git. Uma resposta formatada ou de várias linhas para a pergunta. Use qualquer formatação Markdown desejada, desde que você mantenha o recuo nas linhas após os caracteres | (barra vertical).

Para obter uma breve explicação dos pipelines de implantação, consulte a visão geral dos pipelines de implantação.

Para obter informações sobre licenças, consulte Fabric licenses.

Todos os workspaces devem ser associados a uma licença de Fabric. No entanto, você pode usar diferentes tipos de capacidade para diferentes espaços de trabalho.

Para obter informações sobre os tipos de capacidade, consulte Capacidade e SKUs.

O modelo de permissões de pipelines de implantação é descrito na seção permissões.

Para configurar regras de implantação em pipelines, você deve ser o proprietário do modelo semântico.

Se a capacidade do workspace estiver em uma localização geográfica enquanto o repositório Azure DevOps estiver em outro local, o administrador do Fabric poderá decidir se deseja habilitar as exportações entre áreas geográficas. Para obter mais informações, consulte Usuários podem exportar itens para repositórios Git em outras localizações geográficas.

Comece a usar a integração do Git usando as instruções de introdução.

Pode haver vários motivos pelos quais um item foi removido do espaço de trabalho.

• Se o item não tiver sido confirmado e você o tiver selecionado em uma ação desfazer, o item será removido do espaço de trabalho.
• Se o item foi confirmado, ele poderá ser removido se você alternar entre as ramificações e o item não existir na nova ramificação.

As seguintes considerações são importantes para ter em mente:

• Limitações das regras de implantação
• Fontes de dados com suporte para fluxo de dados e regras de modelo semântico
• Atualização incremental
• Automação

Você pode atribuir um espaço de trabalho ao seu pipeline e implantá-lo em todo o pipeline ou atribuir um espaço de trabalho diferente a cada estágio do pipeline. Para obter mais informações, confira Atribuir um workspace a um pipeline de implantação.

Conjuntos de dados que usam o modo de conectividade DirectQuery ou Composite e têm variação ou tabelas de data/hora automática não têm suporte em pipelines de implantação. Se a implantação falhar e você achar que é porque você tem um conjunto de dados com uma tabela de variação, poderá procurar a propriedade variations nas colunas da tabela. Você pode usar um dos métodos a seguir para editar o modelo semântico para que ele funcione em pipelines de implantação.

• Em seu conjunto de dados, em vez de usar o modo DirectQuery ou Composite, use o modo de importação.

• Remova as tabelas automáticas de data/hora do modelo semântico. Se necessário, exclua todas as variações restantes de todas as colunas em suas tabelas. Excluir uma variação pode invalidar medidas criadas pelo usuário, colunas calculadas e tabelas calculadas. Use esse método somente se você entender como o modelo semântico funciona, pois ele pode resultar em corrupção de dados em seus visuais.

Quando você fixa um bloco em um painel, se o bloco depende de um item não suportado (qualquer item não nesta lista não tem suporte) ou de um item que você não tem permissões para implantar, depois que o painel é implantado, o bloco não é renderizado. Por exemplo, se você criar um bloco a partir de um relatório que depende de um modelo semântico do qual você não é administrador, ao implantar o relatório, você receberá um aviso de erro. No entanto, ao implantar o painel com o bloco, você não recebe uma mensagem de erro, a implantação será bem-sucedida, mas o bloco não exibirá nenhuma informação.

Para uma breve explicação dos planos de implantação, veja a visão geral do plano de implantação.

O tipo de item do plano de implantação aparece somente depois que um administrador do Fabric ativa a configuração de inquilino. No portal de administração, em Configurações do locatário>Microsoft Fabric, habilite Usuários podem criar itens de plano de implantação (versão prévia), defina Aplicar a para toda a organização ou para um grupo de segurança e selecione Aplicar.

Até essa configuração estar ativada, o tipo de item permanece oculto em todos os espaços de trabalho.

A implantação recorre ao comportamento padrão. Itens são implantados sem uma ordem definida e sem ações de pré-implantação ou pós-implantação. Qualquer dependência que estava sendo protegida pelo plano, como uma visão do warehouse que lê uma tabela do lakehouse preenchida por um notebook, volta a falhar.

Um plano corretamente ordenado implanta os metadados dos itens na ordem em que você os declara, mas implantar um lakehouse não insere linhas em suas tabelas. Uma exibição de warehouse que lê uma tabela do lakehouse não consegue se vincular, a menos que essa tabela tenha sido produzida primeiro por um notebook ou pipeline de dados. Adicione uma ação pós-implantação entre a casa do lago e o depósito que produz a mesa. Uma ação é marcada como concluída quando ela própria termina, não quando os serviços que ela alimenta já tenham alcançado esse estado; por isso, coloque toda verificação de prontidão na última célula do notebook ou na última atividade do pipeline de dados. Para um exemplo, veja exemplos de planos de implantação.

O campo lakehouse padrão de um notebook armazena IDs que apontam para um lakehouse específico em um workspace específico. Depois que o notebook chega a um novo espaço de trabalho por meio do Git, esses IDs ainda podem apontar para o espaço de trabalho original. Ou defina a casa do lago padrão para o ambiente alvo nas configurações do notebook antes da execução, ou faça o notebook resolver sua casa do lago em tempo de execução. Para obter mais informações, consulte o controle do código-fonte e a implantação do Notebook.

A saída da execução é visível a partir da implantação no portal. As execuções da ação levam de volta ao histórico de execuções do item subjacente, com logs e detalhes das etapas.

Uma implantação falhada não reverte implantações de itens concluídas ou alterações feitas por ações. Para orientações de recuperação, consulte A implantação foi interrompida no meio do processo.

Não diretamente. Acione Atualização do Git por um agendador externo, como Azure Pipelines ou GitHub Actions, e o plano associado é executado como parte dessa implantação.

Sim, se o pipeline aciona a implantação por meio de uma API do Fabric que oferece suporte à anexação de um plano, como a API de sincronização do Git, a API de implantação dos pipelines de implantação ou a API de importação em lote. Uma implantação conduzida pela CLI do Fabric, o provedor Terraform para Fabric, ou pela biblioteca Python Fabric-cicd não pode anexar um plano.

Não. Um plano define os itens de uma implantação e as ações executadas em torno deles. Configuração em nível de espaço de trabalho não faz parte de uma implantação, então configurações como identidade do workspace, configurações do Spark e conexão Git não são criadas ou atualizadas por um plano.

Configure esses elementos no workspace de destino antes de implantar. Um item que depende da configuração no nível do workspace, como um notebook que se autentica por meio da identidade do workspace, falha durante a execução se o workspace de destino não estiver configurado da mesma forma que o workspace de origem.

Não. Um plano de implantação segue o modelo padrão de trabalho do Fabric. Para mais informações, veja permissões do plano de implantação.

O proprietário de um relatório paginado implantado é o usuário que implantou o relatório. Quando você implantar um relatório paginado pela primeira vez, passará a ser o proprietário do relatório.

Se estiver implantando um relatório paginado em um estágio que já contenha uma cópia desse relatório paginado, você substituirá o relatório anterior e se tornará seu proprietário, em vez do proprietário anterior. Nesses casos, você precisa de credenciais para a fonte de dados subjacente, para que os dados possam ser usados no relatório paginado.

Os sub-relatórios do relatório paginado são mantidos na mesma pasta que contém o relatório paginado. Para evitar problemas de renderização, ao usar a cópia seletiva para copiar um relatório paginado com sub-relatórios, selecione o relatório pai e os sub-relatórios.

As regras de relatório paginados poderão ser criadas se você quiser apontar o relatório paginado para o modelo semântico no mesmo estágio. Ao criar uma regra de implantação para um relatório paginado, você precisará selecionar um banco de dados e um servidor.

Se você estiver definindo uma regra de implantação para um relatório paginado que não tenha um modelo semântico Fabric, porque a fonte de dados de destino é externa, você precisa especificar o servidor e o banco de dados.

No entanto, relatórios paginados que usam um modelo semântico Fabric usam um modelo semântico interno. Nesses casos, você não pode contar com o nome da fonte de dados para identificar o modelo semântico Fabric ao qual está se conectando. O nome da fonte de dados não é alterado quando você o atualiza no estágio de destino, criando uma regra de fonte de dados ou chamando a API de fonte de dados de atualização. Ao definir uma regra de implantação, você precisa manter o formato do banco de dados e substituir a ID do objeto de modelo semântico no campo de banco de dados. Como o modelo semântico é interno, o servidor permanece o mesmo.

• Database - O formato de banco de dados para um relatório paginado com um modelo semântico Fabric é sobe_wowvirtualserver-<dataset ID>. Por exemplo, sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63. Substitua o <dataset ID> pela ID do conjunto de dados. Você pode obter o identificador do conjunto de dados da URL, selecionando o GUID que aparece após datasets/ e antes da próxima barra inclinada.

  

• Servidor – o servidor que hospeda o banco de dados. Mantenha o servidor existente como está.

Após uma implantação, se você baixar o RDL do relatório paginado, ele poderá não ser atualizado com a versão mais recente que você pode ver em serviço do Power BI.

Quando você tem um fluxo de dados que contém modelos semânticos configurados com atualização incremental, a política de atualização não é copiada ou substituída durante a implantação. Depois de implantar um fluxo de dados que inclui um modelo semântico com atualização incremental em um estágio que não inclui esse fluxo de dados, se você tiver uma política de atualização, precisará reconfigurá-la no estágio de destino. Se você estiver implantando um fluxo de dados com atualização incremental em um estágio em que ele já reside, a política de atualização incremental não será copiada. Nesses casos, se você deseja atualizar a política de atualização no estágio de destino, será necessário fazê-lo manualmente.

Conteúdo relacionado

• Introdução à integração do Git
• Introdução aos pipelines de implantação