Cenários de utilização do Power BI: publicação de conteúdo empresarial

Quando os criadores de conteúdo colaboram para fornecer soluções analíticas que são importantes para a organização, eles devem garantir a entrega oportuna e confiável de conteúdo 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.

Os criadores e consumidores de conteúdo 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 comprometa o trabalho em um repositório remoto: os criadores de conteúdo desenvolvem sua solução em sua própria máquina. 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 a 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 uma ramificação. Uma ramificação é uma cópia de um repositório remoto. Quando essas revisões estiverem prontas e aprovadas, a ramificação será mesclada com a versão mais recente da solução. Todas as revisões da solução são rastreadas. Esse processo é conhecido como controle de versão (ou controle do código-fonte).
3. Implantar e promover 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 espaços de trabalho 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 espaços de trabalho do Power BI Premium manualmente usando a interface do usuário ou programaticamente usando as APIs REST. Por outro lado, a publicação de conteúdo corporativo (o foco desse cenário de uso) promove conteúdo usando o Azure Pipelines. Os Pipelines do Azure são um serviço de DevOps do Azure 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ínua (ou CI/CD). Esses pipelines integram alterações com frequência e automaticamente e simplificam a publicação de conteúdo.

O DevOps oferece suporte a uma abordagem madura e sistemática para gerenciamento e publicação de conteúdo. Ele permite que os criadores de conteúdo colaborem em soluções e garante a entrega rápida e confiável de 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.

Você configura e gerencia 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 maneiras diferentes.

• APIs REST do Power BI com pipelines de implantação do Power BI: você pode importar conteúdo para espaços de trabalho de desenvolvimento e usar pipelines de implantação para implantar conteúdo por meio de espaços de trabalho 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 que você acompanhe as alterações no nível do objeto usando o controle de versão. Embora mais robusta e fácil de manter, essa abordagem requer licenciamento Premium e esforço de script moderado 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 do 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 espaços de trabalho de desenvolvimento, teste e produção usando o Azure DevOps e somente as APIs REST do Power BI. Essa abordagem não requer licenciamento Premium, mas envolve alto esforço de script e configuração, porque 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 obter uma comparação visual entre as duas primeiras abordagens, consulte o fluxograma de abordagens do pipeline de liberação.
• Ferramentas de automação do Power BI com pipelines de implantação do Power BI: você pode usar a extensão 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 das ferramentas de automação do Power BI é uma ferramenta de código aberto. Ele ajuda você 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 o mínimo de esforço de script e 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 para seus repositórios remotos e automatizar o teste, a integração e a entrega de conteúdo 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 escolha.

Diagrama de cenário

O diagrama a seguir mostra 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 programaticamente em escala por meio de espaços de trabalho de desenvolvimento, teste e produção no serviço Power BI.

O diagrama de cenário descreve 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 de Tabelas 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 VNet para atualização de dados, como aqueles que residem em uma rede organizacional privada.
	Os criadores de conteúdo regularmente confirmam e enviam suas alterações para um repositório remoto durante o desenvolvimento usando um cliente Git, como o Visual Studio Code. No diagrama, o repositório remoto é Azure Repos.
	Outros criadores de conteúdo usam o Azure Repos para controlar alterações com controle de versão. Eles colaboram comprometendo mudanças em ramos separados.
	As alterações no conteúdo no repositório remoto acionam o Azure Pipelines. Um pipeline de validação é o primeiro pipeline acionado. 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 aciona um pipeline de compilação subsequente. O pipeline de compilação prepara o conteúdo para publicação no serviço do Power BI. O processo até este ponto é normalmente referido como integração contínua (IC).
	O conteúdo é publicado e implantado usando pipelines de versão. Os pipelines de versão usam as APIs REST do Power BI ou o ponto de extremidade XMLA do espaço de trabalho para importar conteúdo programaticamente para o serviço do Power BI. A implantação usando pipelines de liberação é normalmente chamada de implantação contínua (CD).
	Um gerenciador de versão controla a implantação para espaços de trabalho de teste e produção usando uma aprovação de versão do Azure Pipelines. Na publicação de conteúdo corporativo, um gerente de versão normalmente planeja e coordena a liberação de conteúdo para ambientes de teste e produção. Eles coordenam e se comunicam com criadores de conteúdo, partes interessadas e usuários.
	Um pipeline de versão publica conteúdo no espaço de trabalho de desenvolvimento ou promove conteúdo do desenvolvimento para espaços de trabalho de teste, ou teste para espaços de trabalho de produção.
	Os criadores de conteúdo que trabalham em um espaço de trabalho com 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 espaço de trabalho 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 espaço de trabalho privado. As alterações de conteúdo são sincronizadas entre a ramificação remota no Azure Repos e o espaço de trabalho. 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 regularmente alterações do espaço de trabalho após a publicação. Quando estiverem prontos, os criadores de conteúdo podem fazer uma solicitação pull (PR) para mesclar suas alterações na ramificação principal.
	Ao usar a integração Git, o espaço de trabalho de desenvolvimento sincroniza com a ramificação principal para obter as versões mais recentes do conteúdo. Este conteúdo inclui todas as alterações de solicitações pull que um gerente de versão revisa, aprova e mescla.
	Os espaços de trabalho são definidos como Capacidade de malha, Capacidade Premium, Premium por usuário ou Modo de licença incorporado, 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 se alinha a um espaço de trabalho 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 espaço de trabalho de desenvolvimento contém as versões mais recentes do conteúdo, incluindo todas as alterações aprovadas e mescladas. Uma vez aprovado, um pipeline de liberação implanta o conteúdo do desenvolvimento para o espaço de trabalho de teste.
	Os revisores dentro do espaço de trabalho de teste realizam testes e garantia de qualidade no conteúdo. Uma vez aprovado, um pipeline de liberação implanta o conteúdo do teste para o espaço de trabalho de produção. Ao usar a integração do Git com pipelines de implantação, o espaço de trabalho de teste não sincroniza com nenhuma ramificação.
	Depois que o pipeline de implantação conclui a implantação, os criadores de conteúdo executam manualmente as atividades pós-implantação. As atividades podem incluir a configuração da atualização de dados agendada ou a atualização de um aplicativo Power BI para o espaço de trabalho 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 sincroniza com nenhuma ramificação.
	Os visualizadores de conteúdo acessam o conteúdo usando o espaço de trabalho de produção ou um aplicativo do Power BI.

Pontos principais

A seguir estão alguns pontos-chave a serem enfatizados sobre o cenário de publicação de conteúdo corporativo.

Controlo de versões

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

Os criadores de conteúdo normalmente desenvolvem modelos de dados no Editor de Tabelas para oferecer suporte a um melhor controle de versão. Ao contrário de um modelo de dados que você desenvolve no Power BI Desktop, um modelo de dados desenvolvido no Editor de Tabela é salvo no formato de metadados legível por humanos. Esse formato permite 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, consulte o cenário de uso de gerenciamento avançado de modelo de dados. Não é possível ver as alterações feitas em um arquivo do Power BI Desktop (.pbix), como a definição de relatório ou o modelo de dados. Por exemplo, não é possível controlar alterações em uma página de relatório, como os elementos visuais usados, suas posições e seus mapeamentos ou formatação de campo.

Os criadores de conteúdo armazenam arquivos de metadados de modelo de dados e arquivos .pbix em um repositório remoto central, como o Azure Repos. Esses arquivos são curados 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 e revisar as alterações e mesclá-las em uma única solução. O Azure Repos fornece opções sofisticadas para controlar 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 controle de versão. Manter um repositório bem organizado e documentado é essencial porque é a base de todo o conteúdo e colaboração.

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

• Âmbito: Definir claramente o âmbito do repositório. Idealmente, o escopo do repositório é idêntico ao escopo dos espaços de trabalho e aplicativos 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 que configurou para suas permissões de pipeline de implantação e funções de espaço de trabalho. 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 para um repositório remoto, os criadores de conteúdo precisam de um cliente Git como Visual Studio ou Visual Studio Code. O Git é um sistema de controle de versão distribuído que rastreia as alterações em seus arquivos. Para aprender as noções básicas do Git, consulte O que é o Git?.

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. Os 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, você usa serviços de suporte.

• Azure Boards: os proprietários de conteúdo usam quadros para rastrear itens de trabalho. Os itens de trabalho são atribuídos a um único desenvolvedor na equipe e descrevem problemas, bugs ou recursos na solução e as partes interessadas correspondentes.
• Wiki do Azure: os criadores de conteúdo compartilham informações com sua equipe para entender e contribuir com a solução.
• Azure Repos: os criadores de conteúdo controlam 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, automaticamente ou sob demanda.

Fluxograma de colaboração

O diagrama a seguir descreve 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 corporativo. 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 descreve 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 é frequentemente 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 nos Painéis do Azure. Os itens do Works descrevem desenvolvimentos específicos, melhorias ou correções de bugs com escopo para sua ramificação.
	O criador de conteúdo confirma regularmente as suas alterações. Quando estiver pronto, o criador de conteúdo publica sua ramificação no repositório remoto.
	Para testar suas alterações, o criador de conteúdo implanta sua solução em um espaço de trabalho isolado para seu desenvolvimento (não mostrado neste diagrama). O criador de conteúdo também pode sincronizar a ramificação do recurso com o espaço de trabalho usando a integração do Fabric Git.
	Os criadores de conteúdo 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 de conteúdo abre uma solicitação pull para mesclar a ramificação do recurso na ramificação principal.
	Um proprietário técnico é responsável por analisar a solicitação pull e mesclar as alterações. Quando aprovam a solicitação pull, 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 Fabric Git, a ramificação principal é sincronizada com o espaço de trabalho de desenvolvimento.
	O gerente de liberação realiza uma revisão final e aprovação da solução. Essa aprovação de versão impede que a solução seja publicada antes de estar pronta. Na publicação de conteúdo corporativo, um gerente de versão normalmente planeja e coordena a liberação de conteúdo para espaços de trabalho de teste e produção. Eles coordenam e se comunicam com criadores de conteúdo, partes interessadas e usuários.
	Quando o gerenciador de versão aprova a versão, o Azure Pipelines prepara automaticamente a solução para implantação. Como alternativa, um Pipeline do Azure também pode acionar um pipeline de implantação para promover 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 sincroniza com nenhuma ramificação.
	Depois que os usuários aceitam e validam as alterações, o gerenciador de versão executa uma revisão final e aprovação da solução a ser implantada no espaço de trabalho de produção.
	Os usuários visualizam o conteúdo 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 sincroniza com nenhuma ramificação.

Para elaborar, os criadores de conteúdo conseguem a colaboração usando uma estratégia de ramificação. Uma estratégia de ramificação é como os criadores de conteúdo criam, usam e mesclam ramificações para fazer e gerenciar alterações de conteúdo de forma eficaz. Os criadores de conteúdo individuais trabalham isolados em seu repositório local. Quando 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 ramificações, vinculando-as a itens de trabalho para desenvolvimentos específicos, melhorias ou correções de bugs. Cada criador de conteúdo cria sua própria ramificação do repositório remoto para seu escopo de trabalho. O trabalho realizado em sua solução local é confirmado e enviado por push para uma versão da ramificação no repositório remoto com uma mensagem de confirmação. Uma 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 pull. Uma solicitação pull é um envio para revisão por pares que pode levar à fusão do trabalho feito em uma única solução. A fusão pode resultar em conflitos, que devem ser resolvidos antes que a filial possa ser fundida. As revisões de solicitação pull são importantes para garantir que os criadores adiram aos padrões e práticas organizacionais de desenvolvimento, qualidade e conformidade.

Recomendações de colaboração

Recomendamos que você defina um processo estruturado para como os criadores de conteúdo devem colaborar. Certifique-se de determinar:

• Como o trabalho é definido e como as ramificações são criadas, nomeadas e usadas.
• Como os autores agrupam as alterações e descrevem-nas com mensagens de confirmação.
• Quem é responsável por analisar e aprovar os pedidos de pull.
• Como os conflitos de mesclagem são resolvidos.
• Como as mudanças feitas em diferentes ramos são fundidas em um único ramo.
• Como o conteúdo é testado e quem executa o teste antes que o conteúdo seja implantado.
• Como e quando as alterações são implantadas em espaços de trabalho de desenvolvimento, teste e produção.
• Como e quando as alterações implantadas ou versões da solução devem ser revertidas.

APIs REST do Power BI

Você desenvolve 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 espaço de trabalho 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 espaços de trabalho de teste ou produção usando pipelines de implantação do Power BI. A lógica programática é definida nos Pipelines do Azure.

Recomendamos que você use 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 de usuário. No entanto, alguns itens e atividades não são suportados pelas APIs REST do Power BI ou ao usar uma entidade de serviço, como fluxos de dados.

Ao usar uma entidade de serviço, certifique-se de gerenciar cuidadosamente as permissões. Seu objetivo deve ser seguir o princípio do menor privilégio. Você deve definir permissões suficientes para a entidade de serviço sem permissões de provisionamento excessivo. Use o Cofre de Chaves do Azure ou outro serviço que armazene com segurança os segredos e credenciais da entidade de serviço.

Pipelines do Azure

Os Pipelines do Azure automatizam 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 de implantação. Como tal, o número e os tipos de gasodutos 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 Pipelines do Azure que você pode configurar para testar, gerenciar e implantar sua solução do Power BI:

• Pipelines de validação.
• Construa pipelines.
• Canalizações de libertação.

Pipelines de validação

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

Exemplos de testes automatizados incluem a verificação do modelo de dados em busca de violações de regras de práticas recomendadas usando o BPA (Best Practice Analyzer ) ou executando consultas DAX em um modelo semântico publicado. Os resultados desses testes são então armazenados no repositório remoto para fins de documentação e auditoria. Os modelos de dados que falharem na validação não devem ser publicados. Em vez disso, o pipeline deve notificar os criadores de conteúdo sobre os problemas.

Construir pipelines

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

Condutas de libertação

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

• Pipeline de liberação de desenvolvimento: este primeiro pipeline é acionado automaticamente. Ele publica conteúdo em um espaço de trabalho de desenvolvimento depois que os pipelines de compilação e validação são bem-sucedidos.
• Pipelines de liberação de teste e produção: esses pipelines não são acionados automaticamente. Em vez disso, eles são acionados sob demanda ou quando aprovados. Os pipelines de liberação de teste e produção implantam conteúdo em um espaço de trabalho de teste ou produção, respectivamente, após a aprovação da versão. As aprovações de versão 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 versão, que são responsáveis pelo planejamento e coordenação da liberação de conteúdo para ambientes de teste e produção.

Há duas abordagens diferentes para publicar conteúdo com pipelines de teste e 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 diagrama a seguir descreve a primeira abordagem. Nessa abordagem, os pipelines de versão orquestram a implantação de conteúdo para espaços de trabalho de teste e produção usando pipelines de implantação do Power BI. O conteúdo é promovido por meio de espaços de trabalho de desenvolvimento, teste e produção no Power BI. Embora essa abordagem seja mais robusta e simples de manter, ela requer licenciamento Premium.

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

Item	Descrição
	Na primeira abordagem, os pipelines de versão 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, em seguida, promovido por meio de espaços de trabalho 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 ramificação bem-sucedida ou a conclusão de um pipeline upstream aciona o pipeline de compilação. Em seguida, o pipeline de compilação prepara o conteúdo para publicação e aciona o pipeline de lançamento de desenvolvimento.
	O pipeline de versão de desenvolvimento publica conteúdo no espaço de trabalho 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 interface de linha de comando (CLI) do Editor de Tabela para implantar metadados do modelo de dados usando o ponto de extremidade XMLA.
	Uma aprovação de liberação ou gatilho sob demanda ativa o pipeline de liberação de teste.
	O pipeline de liberação de teste implanta conteúdo usando as operações de implantação da API REST do Power BI, que executam o pipeline de implantação do Power BI.
	O pipeline de implantação do Power BI promove conteúdo do espaço de trabalho de desenvolvimento para o espaço de trabalho de teste. Após a implantação, o pipeline de liberação executa atividades pós-implantação usando as APIs REST do Power BI (não mostradas no diagrama).
	Uma aprovação de liberação ou gatilho sob demanda ativa o pipeline de liberação de produção.
	O pipeline de liberação de produção implanta conteúdo usando as operações de implantação da API REST do Power BI, que executam o pipeline de implantação do Power BI.
	O pipeline de implantação do Power BI promove conteúdo do espaço de trabalho de teste para o espaço de trabalho de produção. Após a implantação, o pipeline de liberação executa atividades pós-implantação usando as APIs REST do Power BI (não mostradas no diagrama).

O diagrama a seguir descreve a segunda abordagem. Essa abordagem não usa pipelines de implantação. Em vez disso, ele usa pipelines de versão para publicar conteúdo para espaços de trabalho de teste e 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 esforço de configuração e complexidade, porque você deve gerenciar a implantação fora do Power BI. As equipes de desenvolvimento que já usam 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 descreve as seguintes ações, processos e recursos do usuário na segunda abordagem.

Item	Descrição
	Na segunda abordagem, os pipelines de versão publicam conteúdo usando apenas o ponto de extremidade XMLA e as APIs REST do Power BI. O conteúdo é publicado em espaços de trabalho de desenvolvimento, teste e produção.
	Uma mesclagem de ramificação bem-sucedida ou a conclusão de um pipeline upstream aciona o pipeline de compilação. Em seguida, o pipeline de compilação prepara o conteúdo para publicação e aciona o pipeline de lançamento de desenvolvimento.
	O pipeline de versão de desenvolvimento publica conteúdo no espaço de trabalho 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 interface de linha de comando (CLI) do Editor de Tabela para implantar metadados do modelo de dados usando o ponto de extremidade XMLA.
	Uma aprovação de liberação ou gatilho sob demanda ativa o pipeline de liberação de teste.
	O pipeline de versão de desenvolvimento publica conteúdo no espaço de trabalho de teste usando o ponto de extremidade XMLA (para metadados do modelo de dados) ou 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 interface de linha de comando (CLI) do Editor de Tabela para implantar metadados do modelo de dados usando o ponto de extremidade XMLA. Após a implantação, o pipeline de liberação executa atividades pós-implantação usando as APIs REST do Power BI (não mostradas no diagrama).
	Uma aprovação de liberação ou gatilho sob demanda ativa o pipeline de liberação de produção.
	O pipeline de versão de desenvolvimento publica conteúdo no espaço de trabalho de produção usando o ponto de extremidade XMLA (para metadados do modelo de dados) ou 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 interface de linha de comando (CLI) do Editor de Tabela para implantar metadados do modelo de dados usando o ponto de extremidade XMLA. Após a implantação, o pipeline de liberação executa atividades pós-implantação usando as APIs REST do Power BI (não mostradas no diagrama).

Os pipelines de liberação devem gerenciar as atividades pós-implantação. Essas atividades podem incluir a definição de credenciais de modelo semântico ou a atualização do aplicativo Power BI para espaços de trabalho de teste e produção. Recomendamos que você configure notificações para informar pessoas relevantes sobre as atividades de implantação.

Pipelines de implantação do Power BI

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

Um pipeline de liberação 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 espaço de trabalho e ao pipeline de implantação é necessário para os usuários que conduzem uma implantação. Recomendamos que você planeje 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.

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 o Power BI Premium por usuário (PPU).

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

Configuração do gateway

Normalmente, um gateway de dados é necessário ao acessar fontes de dados que residem na rede organizacional privada 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 em tempo real ou um modelo semântico DirectQuery (não representado no diagrama de cenário).

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

Supervisão do sistema

O log de atividades registra 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 espaço de trabalho, verificar a linhagem e 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 revisar atividades em repositórios e pipelines remotos.

Conteúdos relacionados

Para obter outros cenários úteis para ajudá-lo com decisões de implementação do Power BI, consulte o artigo Cenários de uso do Power BI.