Cenários de uso do Power BI: publicação de conteúdo corporativo

Observação

Este artigo faz parte da série de artigos sobre o Planejamento de implantação do Power BI. Esta série se concentra principalmente na carga de trabalho do Power BI dentro do Microsoft Fabric. Para ter uma introdução a essa série, confira Planejamento de implementação do Power BI.

Quando os criadores de conteúdo colaboram para fornecer soluções analíticas importantes para a organização, eles devem garantir a entrega de conteúdo confiável e no prazo aos consumidores. As equipes técnicas enfrentam esse desafio usando um processo chamado DevOps. O DevOps permite que as equipes automatizem e dimensionem processos adotando práticas que melhoram e aceleram a entrega.

Observação

As equipes de dados que lidam com os mesmos desafios também podem praticar DataOps. O DataOps se baseia em princípios de DevOps, mas o DataOps inclui práticas adicionais específicas ao gerenciamento de dados, como a garantia da qualidade de dados e governança. Nos referimos ao DevOps neste artigo, mas lembre-se de que os princípios subjacentes também podem se aplicar ao DataOps.

Criadores de conteúdo e consumidores se beneficiam de várias vantagens ao adotar práticas de DevOps para publicar conteúdo do Power BI. Os pontos a seguir são uma visão geral de alto nível de como esse processo funciona.

1. Desenvolva conteúdo e confirme o trabalho em um repositório remoto: os criadores de conteúdo desenvolvem sua solução em seu próprio computador. Eles confirmam e salvam seu trabalho em um repositório remoto em intervalos regulares durante o desenvolvimento. Um repositório remoto contém a versão mais recente da solução e é acessível para toda a equipe de desenvolvimento.
2. Colabore e gerencie alterações de conteúdo usando o controle de versão: outros criadores de conteúdo podem fazer revisões na solução criando um branch. Um branch é uma cópia de um repositório remoto. Quando essas revisões estão prontas e aprovadas, o branch é mesclado com a versão mais recente da solução. Todas as revisões da solução são controladas. Esse processo é conhecido como controle de versão (ou controle do código-fonte).
3. Implante e promova o conteúdo usando pipelines: no cenário de uso de publicação de conteúdo de autoatendimento, o conteúdo é promovido (ou implantado) por meio de workspaces de desenvolvimento, teste e produção usando pipelines de implantação do Power BI. Os pipelines de implantação do Power BI podem promover conteúdo para workspaces do Power BI Premium manualmente usando a interface do usuário ou usando as APIs REST de forma programática. Por outro lado, a publicação de conteúdo corporativo (o foco desse cenário de uso) promove o conteúdo usando o Azure Pipelines. O Azure Pipelines é um serviço do Azure DevOps que automatiza o teste, o gerenciamento e a implantação de conteúdo usando uma série de etapas programáticas personalizadas. No cenário de uso de publicação de conteúdo corporativo, esses pipelines também podem ser chamados de pipelines de integração e implantação contínuas (ou CI/CD). Esses pipelines integram alterações com frequência e de forma automática e simplificam a publicação do conteúdo.

O DevOps dá suporte a uma abordagem madura e sistemática para o gerenciamento e publicação do conteúdo. Ele permite que os criadores de conteúdo colaborem em soluções e garante uma entrega rápida e confiável do conteúdo aos consumidores. Ao aderir às práticas de DevOps, você se beneficia de fluxos de trabalho simplificados, menos erros e experiências aprimoradas para criadores de conteúdo e consumidores de conteúdo.

Configure e gerencie as práticas de DevOps para sua solução do Power BI usando o Azure DevOps. Em cenários corporativos, você pode automatizar a publicação de conteúdo com o Azure DevOps e as APIs REST do Power BI de três formas diferentes.

• APIs REST do Power BI com pipelines de implantação do Power BI: você pode importar conteúdo para workspaces de desenvolvimento e usar pipelines de implantação para implantar conteúdo por meio de workspaces de teste e produção. Você ainda controla a implantação do Azure DevOps e usa as APIs REST do Power BI para gerenciar pipelines de implantação em vez de itens de conteúdo individuais. Além disso, você usa o ponto de extremidade XMLA para implantar metadados do modelo de dados em vez de um arquivo do Power BI Desktop (.pbix) com o Azure DevOps. Esses metadados permitem acompanhar as alterações no nível do objeto usando o controle de versão. Embora seja mais robusta e fácil de manter, essa abordagem requer o licenciamento Premium e o trabalho moderado de script para configurar a importação e a implantação de conteúdo com as APIs REST do Power BI. Use essa abordagem quando quiser simplificar o gerenciamento do ciclo de vida de conteúdo com pipelines de implantação e tiver uma licença Premium. O ponto de extremidade XMLA e os pipelines de implantação do Power BI são recursos Premium.
• APIs REST do Power BI: você também pode importar conteúdo para workspaces de desenvolvimento, teste e produção usando o Azure DevOps e apenas as APIs REST do Power BI. Essa abordagem não requer licenciamento Premium, mas envolve alto esforço de script e configuração, pois a implantação é gerenciada fora do Power BI. Use essa abordagem quando quiser implantar o conteúdo do Power BI centralmente a partir do Azure DevOps ou quando não tiver uma licença Premium. Para fazer uma comparação visual entre as duas primeiras abordagens, consulte o diagrama de fluxo de abordagens do pipeline de lançamento.
• Ferramentas de automação do Power BI com pipelines de implantação do Power BI: você pode usar a extensão do Azure DevOps das ferramentas de automação do Power BI para gerenciar pipelines de implantação em vez das APIs REST do Power BI. Essa abordagem é uma alternativa à primeira opção, que usa as APIs REST do Power BI com pipelines de implantação do Power BI. A extensão de ferramentas de automação do Power BI é uma ferramenta de código aberto. Ela ajuda a gerenciar e publicar conteúdo do Azure DevOps sem a necessidade de escrever scripts do PowerShell. Use essa abordagem quando quiser gerenciar pipelines de implantação do Azure DevOps com um esforço mínimo de script e você tiver uma capacidade Premium.

Este artigo se concentra na primeira opção, que usa as APIs REST do Power BI com pipelines de implantação do Power BI. Ele descreve como você pode usar o Azure DevOps para configurar práticas de DevOps. Ele também descreve como você pode usar o Azure Repos em seus repositórios remotos e automatizar o teste de conteúdo, a integração e a entrega com o Azure Pipelines. O Azure DevOps não é a única maneira de configurar a publicação de conteúdo corporativo, mas a integração simples com o Power BI o torna uma boa opção.

Observação

Esse cenário de uso é um dos cenários de gerenciamento e implantação de conteúdo. Para simplificar, alguns aspectos descritos no tópico Cenários de colaboração e entrega de conteúdo não são abordados neste artigo. Para obter a cobertura completa, leia esses artigos primeiro.

Dica

O Microsoft Fabric fornece outras opções para publicação de conteúdo corporativo usando a integração do Git do Fabric. A integração do Git permite vincular um workspace do Fabric a uma ramificação no repositório remoto do Azure Repos. O conteúdo salvo nessa ramificação será sincronizado automaticamente com o workspace, como se esse conteúdo tivesse sido publicado no workspace. Por outro lado, os criadores de conteúdo podem confirmar e enviar as alterações do workspace do Fabric para o repositório remoto.

A integração do Git pode simplificar a colaboração e a publicação de conteúdo, mas requer mais planejamento sobre como você usará os workspaces do Fabric e qual será sua estratégia de ramificação. Para obter mais informações sobre como configurar e usar a integração do Git do Fabric, confira Com usar a integração do Git ou Tutorial: Gerenciamento de ciclo de vida de ponta a ponta.

Diagrama do cenário

O diagrama a seguir ilustra uma visão geral de alto nível das ações mais comuns do usuário e dos componentes do Power BI que dão suporte à publicação de conteúdo corporativo. O foco está no uso do Azure DevOps para gerenciar e publicar conteúdo de forma programática em escala por meio de workspaces de desenvolvimento, teste e produção no serviço do Power BI.

Dica

Recomendamos que você baixe o diagrama de cenário, caso deseje inseri-lo em sua apresentação, documentação ou postagem no blog, ou imprima-o como um pôster de parede. Como ela é uma imagem SVG (Elementos Gráficos Vetoriais Escaláveis), você pode escalá-la ou reduzi-la verticalmente sem perda de qualidade.

O diagrama do cenário ilustra as seguintes ações, processos e recursos do usuário.

Item	Descrição
	Os criadores de conteúdo desenvolvem modelos de dados usando o Power BI Desktop ou o Editor Tabular e desenvolvem relatórios usando o Power BI Desktop. Os criadores de conteúdo salvam seu trabalho em um repositório local durante o desenvolvimento.
	Os criadores de conteúdo podem clonar um repositório remoto para obter uma cópia local desse conteúdo.
	Algumas fontes de dados podem exigir um gateway de dados local ou um gateway de VNet para atualização de dados, como aquelas que estão em uma rede organizacional particular.
	Os criadores de conteúdo confirmam e enviam por push suas alterações a um repositório remoto regularmente durante o desenvolvimento usando um cliente Git, como o Visual Studio Code. No diagrama, o repositório remoto é o Azure Repos.
	Outros criadores de conteúdo usam o Azure Repos para controlar as alterações com o controle de versão. Eles colaboram confirmando alterações em branches separados.
	Alterações no conteúdo do repositório remoto disparam o Azure Pipelines. Um pipeline de validação é o primeiro pipeline que é disparado. O pipeline de validação executa testes automatizados para validar o conteúdo antes de ser publicado.
	O conteúdo que passa pelo pipeline de validação dispara um pipeline de build subsequente. O pipeline de build prepara o conteúdo para publicação no serviço do Power BI. O processo até esse momento geralmente é chamado de integração contínua (CI).
	O conteúdo é publicado e implantado usando pipelines de lançamento. Os pipelines de lançamento usam as APIs REST do Power BI ou o ponto de extremidade XMLA do workspace para importar conteúdo de forma programática para o serviço do Power BI. A implantação usando pipelines de lançamento normalmente é chamada de implantação contínua (CD).
	Um gerenciador de lançamento controla a implantação para workspaces de teste e produção usando uma aprovação de lançamento do Azure Pipelines. Na publicação de conteúdo corporativo, um gerenciador de lançamento normalmente planeja e coordena o lançamento de conteúdo para ambientes de teste e de produção. Eles coordenam e se comunicam com criadores de conteúdo, participantes e usuários.
	Um pipeline de lançamento publica conteúdo no workspace de desenvolvimento ou promove o conteúdo de desenvolvimento para testar workspaces ou testar em workspaces de produção.
	Os criadores de conteúdo que trabalham em um workspace que tem o modo de licença de capacidade do Fabric podem usar a integração do Git. Com a integração do Git, os criadores de conteúdo podem trabalhar em um workspace privado durante o desenvolvimento. O criador de conteúdo sincroniza uma ramificação remota (normalmente uma ramificação de recurso específica ou uma ramificação de bug) do Azure Repos para seu workspace privado. As alterações de conteúdo são sincronizadas entre a ramificação remota no Azure Repos e o workspace. Nesse cenário, os criadores de conteúdo não precisam usar o Azure Pipelines para publicar conteúdo. Os criadores de conteúdo também podem confirmar e enviar alterações regularmente do workspace após a publicação. Quando estiverem prontos, os criadores de conteúdo podem fazer um pull request (PR) para mesclar suas alterações na ramificação principal.
	Ao usar a integração do Git, o workspace de desenvolvimento sincroniza com a ramificação principal para obter as versões mais recentes do conteúdo. Esse conteúdo inclui todas as alterações do pull request que um gerenciador de lançamento revisa, aprova e mescla.
	Os workspaces são definidos como capacidade do Fabric, capacidade Premium, Premium por usuário ou Incorporadomodo de licença, para permitir o uso de pipelines de implantação do Power BI e o ponto de extremidade de leitura/gravação XMLA.
	Um administrador de pipeline de implantação configura o pipeline de implantação do Power BI com três estágios: desenvolvimento, teste e produção. Cada estágio é alinhado a um workspace separado no serviço do Power BI. As configurações de implantação e o acesso são definidos para o pipeline de implantação.
	O workspace de desenvolvimento contém as versões mais recentes do conteúdo, incluindo todas as alterações aprovadas e mescladas. Depois de aprovado, um pipeline de lançamento implanta o conteúdo de desenvolvimento no workspace de teste.
	Os revisores no workspace de teste executam testes e garantia de qualidade no conteúdo. Depois de aprovado, um pipeline de lançamento implanta o conteúdo do teste no workspace de produção. Ao usar a integração do Git com pipelines de implantação, o espaço de trabalho de teste não sera sincronizado com nenhuma ramificação.
	Após a conclusão do pipeline de implantação, os criadores de conteúdo realizam manualmente atividades pós-implantação. As atividades podem incluir a configuração da atualização agendada de dados ou a atualização de um aplicativo do Power BI para o workspace de produção. Ao usar a integração do Git com pipelines de implantação, o espaço de trabalho de produção não será sincronizado com nenhuma ramificação.
	Os espectadores do conteúdo acessam o conteúdo usando o workspace de produção ou um aplicativo do Power BI.

Dica

Recomendamos examinar a publicação de conteúdo de autoatendimento e os cenários de uso de gerenciamento de modelo de dados avançados. O cenário de uso de publicação de conteúdo corporativo se baseia nos conceitos que esses cenários introduzem.

Pontos-chave

Veja a seguir alguns pontos importantes a serem enfatizados sobre o cenário de publicação de conteúdo corporativo.

Controle de versão

Acompanhar as alterações durante o ciclo de vida do conteúdo é importante para garantir a entrega estável e consistente de conteúdo aos consumidores. Nesse cenário de uso, os criadores e proprietários de conteúdo gerenciam alterações de conteúdo em um repositório remoto usando o controle de versão. Controle de versão é a prática de gerenciar alterações em arquivos ou código em um repositório central. Essa prática permite uma melhor colaboração e um gerenciamento eficaz do histórico de versões. O controle de versão tem vantagens para criadores de conteúdo, incluindo a capacidade de reverter ou mesclar alterações.

Os criadores de conteúdo normalmente desenvolvem modelos de dados no Tabular Editor para dar suporte a um melhor controle de versão. Diferentemente de um modelo de dados que você desenvolve no Power BI Desktop, um modelo de dados desenvolvido no Tabular Editor é salvo em formato de metadados legível por humanos. Esse formato habilita o controle de versão no nível do objeto do modelo de dados. Você deve usar o controle de versão no nível do objeto ao colaborar com várias pessoas no mesmo modelo de dados. Para obter mais informações, confira o cenário de uso do gerenciamento de modelo de dados avançados. Não é possível ver as alterações feitas que você fez em um arquivo do Power BI Desktop (.pbix), como a definição do relatório ou o modelo de dados. Por exemplo, você não pode acompanhar alterações em uma página de relatório, como os visuais usados, suas posições, formatação e mapeamentos de campo.

Os criadores de conteúdo armazenam arquivos de metadados do modelo de dados e arquivos .pbix em uma repositório remoto central, como o Azure Repos. Esses arquivos são coletados por um proprietário técnico. Enquanto um criador de conteúdo desenvolve uma solução, um proprietário técnico é responsável por gerenciar a solução, analisar as alterações e mesclá-las em uma única solução. O Azure Repos oferece opções sofisticadas para acompanhar e gerenciar alterações. Essa abordagem difere da abordagem descrita no cenário de uso de publicação de conteúdo de autoatendimento, em que o criador usa o armazenamento do OneDrive com o controle de versão. Manter um repositório bem coletado e documentado é essencial porque é a base de todo o conteúdo e colaboração.

Aqui estão algumas considerações importantes para ajudá-lo na configuração de um repositório remoto para o controle de versão.

• Escopo: defina claramente o escopo do repositório. Idealmente, o escopo do repositório é idêntico ao escopo de aplicativos e workspaces downstream que você usa para fornecer conteúdo aos consumidores.
• Acesso: você deve configurar o acesso ao repositório usando um modelo de permissões semelhante ao configurado em suas permissões de pipeline de implantação e funções de workspace. Os criadores de conteúdo precisam de acesso ao repositório.
• Documentação: adicione arquivos de texto ao repositório para documentar sua finalidade, propriedade, acesso e processos definidos. Por exemplo, a documentação pode descrever como as alterações devem ser preparadas e confirmadas.
• Ferramentas: para confirmar e enviar alterações por push a um repositório remoto, os criadores de conteúdo precisam de um cliente Git como o Visual Studio ou o Visual Studio Code. O Git é um sistema de controle de versão distribuído que acompanha as alterações nos seus arquivos. Para conhecer as noções básicas do Git, consulte O que é o Git?.

Observação

Considere o uso do Armazenamento de Arquivos Grandes do Git (LFS) se você planeja confirmar arquivos do Power BI Desktop (.pbix). O Git LFS oferece opções avançadas para o gerenciamento de arquivos em que as alterações não são visíveis (arquivos indiferenciáveis), como um arquivo .pbix. Por exemplo, você pode usar o bloqueio de arquivos para evitar alterações simultâneas em um relatório do Power BI durante o desenvolvimento. Entretanto, o Git LFS tem seu próprio cliente e configuração.

Colaboração com o Azure DevOps

À medida que uma solução aumenta em escopo e complexidade, pode se tornar necessário que vários criadores e proprietários de conteúdo trabalhem em colaboração. Criadores e proprietários de conteúdo se comunicam e colaboram em um hub central e organizado usando o Azure DevOps.

Para colaborar e se comunicar no Azure DevOps, use os serviços de suporte.

• Azure Boards: os proprietários de conteúdo usam o Boards para acompanhar itens de trabalho. Os itens de trabalho são atribuídos a um único desenvolvedor na equipe e eles descrevem problemas, bugs ou recursos na solução e os participantes correspondentes.
• Wiki do Azure: os criadores de conteúdo compartilham informações com sua equipe para entender e contribuir na solução.
• Azure Repos: os criadores de conteúdo acompanham as alterações no repositório remoto e as mesclam em uma única solução.
• Azure Pipelines: os proprietários de pipeline configuram a lógica programática para implantar a solução, seja automaticamente ou sob demanda.

Diagrama de fluxo de colaboração

O diagrama a seguir mostra uma visão geral de alto nível de um exemplo de como o Azure DevOps permite a colaboração no cenário de uso de publicação de conteúdo empresarial. O foco deste diagrama está no uso do Azure DevOps para criar um processo de publicação de conteúdo estruturado e documentado.

O diagrama ilustra as seguintes ações, processos e recursos do usuário.

Item	Descrição
	Um criador de conteúdo cria uma nova ramificação de curta duração clonando a ramificação principal, que contém a versão mais recente do conteúdo. A nova ramificação é geralmente chamada de ramificação de recurso, pois é usada para desenvolver um recurso específico ou corrigir um problema específico.
	O criador de conteúdo confirma suas alterações em um repositório local durante o desenvolvimento.
	O criador de conteúdo vincula suas alterações a itens de trabalho gerenciados no Azure Boards. Os itens de trabalho descrevem desenvolvimentos, melhorias ou correções de bugs específicos com escopo para seu branch.
	O criador de conteúdo confirma suas alterações regularmente. Quando estiver pronto, o criador de conteúdo publicará seu branch no repositório remoto.
	Para testar suas alterações, o criador de conteúdo implementa sua solução em um espaço de trabalho isolado para seu desenvolvimento (não mostrado neste diagrama). O criador do conteúdo também pode sincronizar a ramificação do recurso com o espaço de trabalho usando a integração do Git do Fabric.
	Criadores e proprietários de conteúdo documentam a solução e seus processos em um Wiki do Azure, que está disponível para toda a equipe de desenvolvimento.
	Quando estiver pronto, o criador do conteúdo abrirá uma pull request para mesclar a ramificação do recurso na ramificação principal.
	Um proprietário técnico é responsável por analisar a solicitação de pull e mesclar as alterações. Quando eles aprovam a pull request, eles mesclam a ramificação do recurso na ramificação principal.
	Uma mesclagem bem-sucedida aciona a implantação da solução em um espaço de trabalho de desenvolvimento usando um Pipeline do Azure (não mostrado neste diagrama). Ao usar a integração do Git do Fabric, a ramificação principal será sincronizada com o espaço de trabalho de desenvolvimento.
	O gerenciador de lançamento executa uma revisão final e aprova a solução. Essa aprovação de lançamento impede que a solução seja publicada antes de estar pronta. Na publicação de conteúdo empresarial, um gerente de versão normalmente planeja e coordena a versão do conteúdo para os espaços de trabalho de teste e produção. Eles coordenam e se comunicam com criadores de conteúdo, participantes e usuários.
	Quando o gerenciador de lançamento aprova o lançamento, o Azure Pipelines prepara automaticamente a solução para implantação. Como alternativa, um pipeline do Azure também pode disparar um pipeline de implantação para promover um conteúdo entre espaços de trabalho.
	Os usuários testam e validam o conteúdo no espaço de trabalho de teste. Ao usar a integração do Git com o Azure Pipelines para implantação, o espaço de trabalho de teste não será sincronizado com nenhuma ramificação.
	Depois que os usuários aceitam e validam as alterações, o gerente de versão faz uma revisão final e aprova a solução a ser implantada no espaço de trabalho de produção.
	Os usuários visualizam o conteúdo que foi publicado no espaço de trabalho de produção. Ao usar a integração do Git com o Azure Pipelines para implantação, o espaço de trabalho de produção não é sincronizado com nenhuma ramificação.

Para elaborar, os criadores de conteúdo colaboram usando uma estratégia de ramificação. Uma estratégia de ramificação é a forma como os criadores de conteúdo criam, usam e mesclam ramificações para fazer e gerenciar alterações de conteúdo com eficiência. Os criadores de conteúdo individuais trabalham isoladamente em seu repositório local. Quando estiverem prontos, eles combinam suas alterações como uma única solução no repositório remoto. Os criadores de conteúdo devem definir o escopo de seu trabalho para branches vinculando-os a itens de trabalho para desenvolvimentos, melhorias ou correções de bugs específicos. Cada criador de conteúdo cria seu próprio branch do repositório remoto para seu escopo de trabalho. O trabalho realizado em sua solução local é confirmado e enviado para uma versão do branch no repositório remoto com uma mensagem de confirmação. Um mensagem de confirmação descreve as alterações feitas nessa confirmação.

Para mesclar as alterações, um criador de conteúdo abre uma solicitação de pull. Uma solicitação de pull é um envio para revisão em pares que pode resultar na mesclagem do trabalho feito em uma única solução. A mesclagem pode resultar em conflitos, que devem ser resolvidos antes que o branch seja mesclado. As análises da solicitação de pull são importantes para garantir que os criadores respeitem os padrões e as práticas organizacionais de desenvolvimento, qualidade e conformidade.

Recomendações de colaboração

Recomendamos definir um processo estruturado de como os criadores de conteúdo devem colaborar. Determine:

• Como o trabalho é escopado e como os branches são criados, nomeados e usados.
• Como os autores agrupam alterações e as descrevem com mensagens de confirmação.
• Quem é responsável por analisar e aprovar as solicitações de pull.
• Como os conflitos de mesclagem são solucionados.
• Como as alterações feitas em branches diferentes são mescladas em um único branch.
• Como o conteúdo é testado e quem executa os testes antes da implantação do conteúdo.
• Como e quando as alterações são implantadas em workspaces de desenvolvimento, teste e produção.
• Como e quando as alterações ou versões implantadas da solução devem ser revertidas.

Importante

O valor fornecido pelo DevOps é diretamente proporcional à adesão aos processos que definem seu uso.

Uma colaboração bem-sucedida depende de um processo bem definido. É importante descrever e documentar de forma clara o fluxo de trabalho de desenvolvimento de ponta a ponta. Verifique se as estratégias e os processos selecionados estão alinhados com as práticas existentes em sua equipe e, caso contrário, como você gerenciará as alterações. Além disso, verifique se os processos estão claros e se foram comunicados a todos os membros da equipe e aos participantes. Certifique-se de que os membros da equipe e os participantes que não conhecem os processos recebam treinamento em como adotá-los e que eles valorizem a adoção bem-sucedida do DevOps.

APIs REST do Power BI

Você desenvolve uma lógica programática para importar e implantar conteúdo do Azure DevOps usando as APIs REST do Power BI. Você importa arquivos do Power BI (.pbix) para um workspace usando uma operação de importação. Você usa uma operação de pipeline para implantar algum conteúdo ou todo o conteúdo em workspaces de teste ou produção usando pipelines de implantação do Power BI. A lógica programática é definida no Azure Pipelines.

Recomendamos usar uma entidade de serviço para chamar APIs REST do Power BI em seus pipelines. Uma entidade de serviço destina-se a atividades autônomas e automatizadas e não depende de credenciais do usuário. No entanto, alguns itens e atividades não são compatíveis com as APIs REST do Power BI ou ao usar uma entidade de serviço, como fluxos de dados.

Ao usar uma entidade de serviço, gerencie as permissões com cuidado. Seu objetivo deve ser seguir o princípio de privilégios mínimos. Você deve definir permissões suficientes para a entidade de serviço sem estabelecer permissões em excesso. Use o Azure Key Vault ou outro serviço que armazene com segurança os segredos e as credenciais da entidade de serviço.

Cuidado

Se você tiver um modelo de dados salvo em um formato de metadados legível por humanos, ele não poderá ser publicado usando as APIs REST do Power BI. Em vez disso, você deve publicá-lo usando o ponto de extremidade XMLA. Você pode publicar arquivos de metadados usando ferramentas de terceiros, como a CLI ( interface de linha de comando) do Editor Tabular . Você também pode publicar arquivos de metadados de forma programática usando seu próprio desenvolvimento personalizado do .NET. O desenvolvimento de uma solução personalizada requer mais trabalho, pois você deve usar a extensão TOM (Modelo de Objeto Tabular da Microsoft) das bibliotecas de clientes AMO (Objeto de Gerenciamento de Análise).

Azure Pipelines

O Azure Pipelines automatiza programaticamente o teste, o gerenciamento e a implantação de conteúdo. Quando um pipeline é executado, as etapas no pipeline são executadas automaticamente. Os proprietários de pipeline podem personalizar seus gatilhos, etapas e funcionalidades para atender às necessidades da implantação. Dessa forma, o número e os tipos de pipelines variam dependendo dos requisitos da solução. Por exemplo, um Pipeline do Azure pode executar testes automatizados ou modificar parâmetros de modelo de dados antes de uma implantação.

Há três tipos de Azure Pipelines que você pode configurar para testar, gerenciar e implantar sua solução do Power BI:

• Pipelines de validação.
• Pipelines de build.
• Pipelines de lançamento.

Observação

Não é necessário ter todos esses três pipelines em sua solução de publicação. Dependendo do fluxo de trabalho e das necessidades, você pode configurar uma ou mais variantes dos pipelines descritos neste artigo para automatizar a publicação de conteúdo. Essa capacidade de personalizar os pipelines é uma vantagem do Azure Pipelines em relação aos pipelines de implantação internos do Power BI. Por exemplo, você não precisa ter um pipeline de validação. Você só pode usar pipelines de build e de lançamento.

Pipelines de validação

Os pipelines de validação executam verificações básicas de qualidade dos modelos de dados antes de serem publicados em um workspace de desenvolvimento. Normalmente, as alterações em um branch do repositório remoto disparam o pipeline para validar essas alterações com testes automatizados.

Exemplos de testes automatizados incluem a digitalização do modelo de dados para buscar violações de regras de melhor prática usando o Analisador de Melhor Prática (BPA) ou a execução de consultas DAX em um modelo semântico publicado. Os resultados desses testes são armazenados no repositório remoto para fins de documentação e auditoria. Os modelos de dados que não são aprovados na validação não devem ser publicados. Em vez disso, o pipeline deve notificar os criadores de conteúdo sobre os problemas.

Pipelines de build

Os pipelines de build preparam modelos de dados para publicação no serviço do Power BI. Esses pipelines combinam metadados de modelo serializados em um único arquivo publicado posteriormente por um pipeline de lançamento (descrito no diagrama de pipelines de lançamento). Um pipeline de build também pode fazer outras alterações nos metadados, como modificar valores de parâmetro. Os pipelines de build produzem artefatos de implantação que consistem em metadados do modelo de dados (para modelos de dados) e arquivos do Power BI Desktop (.pbix) prontos para publicação no serviço do Power BI.

Pipelines de lançamento

Os pipelines de lançamento publicam ou implantam conteúdo. Uma solução de publicação normalmente inclui vários pipelines de lançamento, dependendo do ambiente de destino.

• Pipeline de lançamento de desenvolvimento: esse primeiro pipeline é disparado automaticamente. Ele publica conteúdo em um workspace de desenvolvimento depois que os pipelines de build e validação são bem-sucedidos.
• Pipelines de lançamento de teste e produção: esses pipelines não são disparados automaticamente. Em vez disso, eles são disparados sob demanda ou quando aprovados. Os pipelines de lançamento de teste e produção implantam conteúdo em um workspace de teste ou produção, respectivamente, após a aprovação do lançamento. As aprovações de lançamento garantem que o conteúdo não seja implantado automaticamente em um estágio de teste ou produção antes de estar pronto. Essas aprovações são fornecidas por gerentes de lançamento, responsáveis por planejar e coordenar a liberação de conteúdo para ambientes de teste e de produção.

Há duas abordagens diferentes para publicar conteúdo com pipelines de teste e de lançamento. Eles promovem conteúdo usando um pipeline de implantação do Power BI ou publicam conteúdo no serviço do Power BI a partir do Azure DevOps.

O seguinte diagrama representa a primeira abordagem. Nessa abordagem, os pipelines de lançamento controlam a implantação de conteúdo para workspaces de teste e de produção usando pipelines de implantação do Power BI. O conteúdo é promovido por meio de workspaces de desenvolvimento, teste e produção no Power BI. Embora essa abordagem seja mais robusta e mais simples de manter, ela requer licenciamento Premium.

O diagrama ilustra as seguintes ações, processos e recursos do usuário da primeira abordagem.

Item	Descrição
	Na primeira abordagem, os pipelines de lançamento publicam conteúdo usando o ponto de extremidade XMLA e as APIs REST do Power BI com pipelines de implantação do Power BI. O conteúdo é publicado e depois promovido por meio de workspaces de desenvolvimento, teste e produção. Os pipelines de implantação do Power BI e o ponto de extremidade de leitura/gravação XMLA são recursos Premium.
	Uma mesclagem de branch bem-sucedida ou a conclusão de um pipeline upstream dispara o pipeline de build. Em seguida, o pipeline de build prepara o conteúdo para publicação e dispara o pipeline de lançamento de desenvolvimento.
	O pipeline de lançamento de desenvolvimento publica conteúdo no workspace de desenvolvimento usando o ponto de extremidade XMLA (para metadados do modelo de dados) ou as APIs REST do Power BI (para arquivos do Power BI Desktop, que podem conter modelos de dados e relatórios). O pipeline de desenvolvimento usa a CLI (interface de linha de comando) do Editor Tabular para implantar metadados do modelo de dados usando o ponto de extremidade XMLA.
	Um gatilho sob demanda ou aprovação de lançamento ativa o pipeline de lançamento de teste.
	O pipeline de lançamento de teste implanta o conteúdo usando as operações de implantação da API REST do Power BI, que executam o pipeline da implantação do Power BI.
	O pipeline de implantação do Power BI promove o conteúdo do workspace de desenvolvimento para o workspace de teste. Após a implantação, o pipeline de lançamento executa atividades pós-implantação usando as APIs REST do Power BI (não mostradas no diagrama).
	Um gatilho sob demanda ou aprovação de lançamento ativa o pipeline de lançamento de produção.
	O pipeline de lançamento de produção implanta o conteúdo usando as operações de implantação da API REST do Power BI, que executam o pipeline da implantação do Power BI.
	O pipeline de implantação do Power BI promove o conteúdo do workspace de teste para o workspace de produção. Após a implantação, o pipeline de lançamento executa atividades pós-implantação usando as APIs REST do Power BI (não mostradas no diagrama).

O seguinte diagrama representa a segunda abordagem. Essa abordagem não usa pipelines de implantação. Em vez disso, ela usa pipelines de lançamento para publicar conteúdo para workspaces de teste e de produção do Azure DevOps. Notavelmente, essa segunda abordagem não requer licenciamento Premium quando você publica apenas arquivos do Power BI Desktop com as APIs REST do Power BI. Isso envolve mais trabalho e complexidade de configuração, pois você deve gerenciar a implantação fora do Power BI. As equipes de desenvolvimento que já usam o DevOps para soluções de dados fora do Power BI podem estar mais familiarizadas com essa abordagem. As equipes de desenvolvimento que usam essa abordagem podem consolidar a implantação de soluções de dados no Azure DevOps.

O diagrama ilustra as seguintes ações, processos e recursos do usuário na segunda abordagem.

Item	Descrição
	Na segunda abordagem, os pipelines de lançamento publicam conteúdo usando o ponto de extremidade XMLA e apenas as APIs REST do Power BI. O conteúdo é publicado em workspaces de desenvolvimento, teste e produção.
	Uma mesclagem de branch bem-sucedida ou a conclusão de um pipeline upstream dispara o pipeline de build. Em seguida, o pipeline de build prepara o conteúdo para publicação e dispara o pipeline de lançamento de desenvolvimento.
	O pipeline de lançamento de desenvolvimento publica conteúdo no workspace de desenvolvimento usando o ponto de extremidade XMLA (para metadados do modelo de dados) ou as APIs REST do Power BI (para arquivos do Power BI Desktop, que podem conter modelos de dados e relatórios). O pipeline de desenvolvimento usa a CLI (interface de linha de comando) do Editor Tabular para implantar metadados do modelo de dados usando o ponto de extremidade XMLA.
	Um gatilho sob demanda ou aprovação de lançamento ativa o pipeline de lançamento de teste.
	O pipeline de lançamento de desenvolvimento publica conteúdo no workspace de teste usando o ponto de extremidade XMLA (para metadados do modelo de dados) ou as APIs REST do Power BI (para arquivos do Power BI Desktop, que podem conter modelos de dados e relatórios). O pipeline de desenvolvimento usa a CLI (interface de linha de comando) do Editor Tabular para implantar metadados do modelo de dados usando o ponto de extremidade XMLA. Após a implantação, o pipeline de lançamento executa atividades pós-implantação usando as APIs REST do Power BI (não mostradas no diagrama).
	Um gatilho sob demanda ou aprovação de lançamento ativa o pipeline de lançamento de produção.
	O pipeline de lançamento de desenvolvimento publica conteúdo no workspace de produção usando o ponto de extremidade XMLA (para metadados do modelo de dados) ou as APIs REST do Power BI (para arquivos do Power BI Desktop, que podem conter modelos de dados e relatórios). O pipeline de desenvolvimento usa a CLI (interface de linha de comando) do Editor Tabular para implantar metadados do modelo de dados usando o ponto de extremidade XMLA. Após a implantação, o pipeline de lançamento executa atividades pós-implantação usando as APIs REST do Power BI (não mostradas no diagrama).

Os pipelines de lançamento devem gerenciar atividades pós-implantação. Essas atividades podem incluir a configuração de credenciais de modelo semântico ou a atualização do aplicativo Power BI para workspaces de teste e produção. Recomendamos configurar as notificações para informar as pessoas relevantes sobre as atividades de implantação.

Dica

O uso de um repositório para controle de versão permite que os criadores de conteúdo criem um processo de reversão. O processo de reversão pode reverter a última implantação restaurando a versão anterior. Considere criar um conjunto separado de Azure Pipelines que você pode disparar para reverter as alterações de produção. Reflita com cuidado sobre quais processos e aprovações são necessários para iniciar uma reversão. Verifique se esses processos estão documentados.

Pipelines de implantação do Power BI

Um pipeline de implantação do Power BI é composto por três estágios: desenvolvimento, teste e produção. Você atribui um único workspace do Power BI a cada estágio no pipeline de implantação. Quando uma implantação ocorre, o pipeline de implantação promove itens do Power BI de um workspace para outro.

Um pipeline de lançamento do Azure Pipelines usa as APIs REST do Power BI para implantar conteúdo usando um pipeline de implantação do Power BI. O acesso ao workspace e ao pipeline de implantação é necessário para os usuários que conduzem uma implantação. Recomendamos planejar o acesso ao pipeline de implantação para que os usuários do pipeline possam exibir o histórico de implantação e comparar o conteúdo.

Dica

Ao separar workspaces de dados de workspaces de relatórios, considere usar o Azure Pipelines para controlar a publicação de conteúdo com vários pipelines de implantação do Power BI. Os modelos semânticos são implantados primeiro e depois são atualizados. Por fim, os relatórios são implantados. Essa abordagem ajuda a simplificar a implantação.

Licenciamento Premium

Os pipelines de implantação do Power BI e o ponto de extremidade de leitura/gravação XMLA são recursos Premium. Esses recursos estão disponíveis com a capacidade do Power BI Premium e PPU (Power BI Premium por usuário).

O PPU é uma maneira econômica de gerenciar a publicação de conteúdo corporativo para workspaces de desenvolvimento e de teste, que normalmente têm poucos usuários. Essa abordagem tem a vantagem adicional de isolar cargas de trabalho de desenvolvimento e de teste de cargas de trabalho de produção.

Observação

Você ainda pode configurar a publicação de conteúdo corporativo sem uma licença Premium, conforme descrito na seção pipeline de lançamento da segunda abordagem. Na segunda abordagem, você usa o Azure Pipelines para gerenciar a implantação de arquivos do Power BI Desktop para workspaces de desenvolvimento, teste e produção. No entanto, você não pode implantar metadados de modelo usando o ponto de extremidade XMLA porque não é possível publicar um modelo semântico de formato de metadados com as APIs REST do Power BI. Além disso, não é possível promover o conteúdo por meio de ambientes com pipelines de implantação sem uma licença Premium.

Instalação do gateway

Normalmente, um gateway de dados é necessário ao acessar fontes de dados que residem na rede organizacional particular ou em uma rede virtual. As duas finalidades de um gateway são atualizar dados importados e exibir um relatório que consulta uma conexão dinâmica ou um modelo semântico do DirectQuery (não ilustrado no diagrama do cenário).

Ao trabalhar com vários ambientes, é comum configurar conexões de desenvolvimento, teste e produção para sistemas de origem diferentes. Nesse caso, use regras de fonte de dados e regras de parâmetros para gerenciar valores que diferem entre ambientes. Você pode usar o Azure Pipelines para gerenciar gateways usando as operações de gateway das APIs REST do Power BI.

Observação

Um gateway de dados centralizado no modo padrão é altamente recomendado, em vez de gateways no modo pessoal. No modo padrão, o gateway de dados dá suporte a operações de conexão dinâmica e do DirectQuery (além das operações de atualização de dados agendadas).

Supervisão do sistema

O log de atividades registra os eventos que ocorrem no serviço do Power BI. Os administradores do Power BI podem usar o log de atividades para auditar as atividades de implantação.

Você pode usar as APIs de verificação de metadados do Power BI para criar um inventário de locatário. Os resultados da API são úteis para verificar quais itens foram implantados em cada workspace, para verificar a linhagem e para validar as configurações de segurança.

Há também um log de auditoria no Azure DevOps, que está fora do serviço do Power BI. Os administradores do Azure DevOps podem usar o log de auditoria para analisar as atividades em pipelines e repositórios remotos.

Conteúdo relacionado

Para outros cenários úteis para ajudar com decisões de implementação do Power BI, confira o artigo Cenários de uso do Power BI.