Perguntas frequentes sobre as ferramentas de gestão do ciclo de vida do Fabric

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

Para obter uma breve explicação sobre a integração do Git, consulte a visão geral da integração do Git. Uma resposta multilinha ou formatada para a pergunta. Use qualquer formatação de Markdown desejada, desde que mantenha o recuo nas linhas após o | caracteres.

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

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

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

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

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

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

Se a capacidade do espaço de trabalho estiver numa localização geográfica enquanto o repositório Azure DevOps estiver noutra localização, o administrador do Fabric pode decidir se ativa as exportações entre geolocalizações. Para obter mais informações, consulte Os usuários podem exportar itens para repositórios Git em outros locais geográficos.

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

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

• Caso o item não tenha sido confirmado e o utilizador o selecione em uma ação , o item será removido do espaço de trabalho.
• Se o item for confirmado, ele pode ser removido se mudar de ramo e o item não existir no novo ramo.

É importante ter em mente as seguintes considerações:

• Limitações da regra de implantação
• Fontes de dados suportadas para regras de modelo semântico e de fluxo de dados
• Atualização incremental
• Automação

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

Os conjuntos de dados que usam o modo de conectividade DirectQuery ou Composite e têm variação ou tabelas de data/hora automáticas não são compatíveis com os pipelines de implantação. Se a implantação falhar e achar que é porque tem um conjunto de dados com uma tabela de variações, poderá procurar a propriedade variations nas colunas da sua tabela. Você pode usar um dos seguintes métodos para editar seu modelo semântico para que ele funcione em pipelines de implantação.

• No conjunto de dados, em vez de usar o DirectQuery ou o modo Composto, use o modo de importação .

• Remova as tabelas automáticas de data/hora do seu modelo semântico. Se necessário, exclua as variações restantes de todas as colunas das tabelas. A exclusão de uma variação pode invalidar medidas criadas pelo usuário, colunas calculadas e tabelas calculadas. Use este método somente se entender como o seu modelo semântico funciona, pois pode resultar em danos nos dados nas suas visualizações.

Quando fixas um tile num dashboard, se o tile depender de um item não suportado (qualquer item que não esteja nesta lista não é suportado), ou num item para o qual não tens permissões para implementar, depois de implementares o dashboard o tile deixa de ser renderizado. Por exemplo, se você criar um bloco a partir de um relatório que depende de um modelo semântico no qual 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, consulte a visão geral do plano de implantação.

O tipo de item do plano de implementação só aparece depois de um administrador do Fabric ativar a definição de inquilino. No portal de administração, em Definições do inquilino>Microsoft Fabric, ative Os utilizadores podem criar itens de plano de implementação (pré-visualização), defina Aplicar a para toda a organização ou para um grupo de segurança e selecione Aplicar.

Até que esta definição esteja ativada, o tipo de item permanece oculto em todos os espaços de trabalho.

A implementação volta ao seu comportamento padrão. Os itens são implementados sem uma ordem definida e sem ações de pré-implementação ou pós-implementação. Qualquer dependência que o plano protegia, como uma vista do armazém que lê uma tabela do lakehouse preenchida por um notebook, volta a falhar.

Um plano corretamente ordenado implementa os metadados dos itens pela ordem em que os declara, mas a implementação de uma lakehouse não insere linhas nas respetivas tabelas. Uma vista warehouse que lê uma tabela lakehouse falha em vincular a menos que um caderno ou pipeline de dados tenha produzido essa tabela primeiro. Adicione uma ação pós-implementação entre o lakehouse e o armazém de dados que cria a tabela. Uma ação assinala a conclusão quando a própria ação termina, não quando os serviços que alimenta já a acompanharam, por isso coloque qualquer 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 predefinido de um notebook contém identificadores que apontam para um lakehouse específico num espaço de trabalho específico. Depois de o caderno aterrar num novo espaço de trabalho através do Git, esses IDs ainda podem apontar para o espaço de trabalho original. Ou defines a lakehouse predefinida para o ambiente de destino nas definições do notebook antes da execução, ou fazes com que o notebook determine a sua lakehouse em tempo de execução. Para mais informações, consulte controlo de origem e implementação do Notebook.

O resultado da execução está visível na implementação no portal. As execuções de ação ligam de volta ao histórico de execuções do item subjacente para registos e detalhes dos passos.

Uma implementação falhada não reverte as implementações de itens concluídas nem as alterações feitas por ações. Para obter orientações para recuperação, veja A implementação foi interrompida a meio.

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

Sim, se o pipeline conduz a implementação através de uma API Fabric que suporta anexar um plano, como a API de sincronização do Git, a API de deployment pipeline ou a API de importação por lote. Uma implementação conduzida pelo Fabric CLI, o fornecedor Terraform para Fabric, ou pela biblioteca Python fabric-cicd não pode anexar um plano.

No. Um plano governa os itens numa implementação e as ações que os rodeiam. A configuração ao nível do espaço de trabalho não faz parte de uma implementação, por isso definições como a identidade do espaço de trabalho, definições do Spark e a ligação Git não são criadas nem atualizadas por um plano.

Configure-os no espaço de trabalho de destino antes de implementar. Um item que depende da configuração ao nível do espaço de trabalho, como um caderno que autentica através da identidade do espaço de trabalho, falha em tempo de execução se o espaço de trabalho alvo não estiver configurado da mesma forma que a fonte.

No. Um plano de implementação segue o modelo padrão do espaço de trabalho Fabric. Para mais informações, consulte permissões do plano de implantação.

O proprietário de um relatório paginado implantado é o usuário que implantou o relatório. Ao implantar um relatório paginado pela primeira vez, você se torna o proprietário do relatório.

Se estiver a implantar um relatório paginado num estágio que já contém uma cópia desse relatório paginado, substituirá o relatório anterior e tornar-se-á o 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 de relatório paginados são mantidos na mesma pasta que contém o relatório paginado. Para evitar problemas de renderização, quando você estiver usando uma 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 paginado podem 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ê precisa selecionar um banco de dados e um servidor.

Se estiveres a definir uma regra de deployment para um relatório paginado que não tem um modelo semântico Fabric, porque a fonte de dados alvo é externa, precisas de especificar tanto o servidor como a base de dados.

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

• Database - O formato de base 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> pelo ID do seu conjunto de dados. Você pode obter o ID do conjunto de dados da URL, selecionando o GUID que vem depois datasets/ e antes da próxima barra.

  

• Servidor - O servidor que hospeda seu banco de dados. Mantenha o servidor existente como está.

Após uma implementação, se descarregar o RDL do relatório paginado, pode não ser atualizado com a versão mais recente que pode ver no serviço 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 para 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 onde 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, você precisa fazê-lo manualmente.

Conteúdos relacionados

• Introdução à integração com o Git
• Comece com os pipelines de implantação