Planejamento de implementação do Power BI: desenvolver conteúdo e gerenciar alterações

Observação

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

Este artigo ajudará você a desenvolver conteúdo e gerenciar alterações como parte do gerenciamento do ciclo de vida do conteúdo. Ele é voltado principalmente para:

• Equipes de COE (Centro de Excelência) e BI: as equipes responsáveis por supervisionar o Power BI na organização. Essas equipes incluem tomadores de decisão que decidem como gerenciar o ciclo de vida do conteúdo do Power BI. Essas equipes também podem incluir funções como gerentes de versão, que lidam com o ciclo de vida das versões de conteúdo, ou engenheiros que criam e gerenciam os componentes necessários para usar e dar suporte eficaz ao gerenciamento do ciclo de vida.
• Criadores de conteúdo e proprietários de conteúdo: usuários que criam conteúdo que querem publicar no portal do Fabric para compartilhar com outras pessoas. Esses indivíduos são responsáveis por gerenciar o ciclo de vida do conteúdo do Power BI que eles criam.

O gerenciamento do ciclo de vida são os processos e práticas que você usa para lidar com o conteúdo, desde sua criação até sua eventual desativação. No primeiro estágio do gerenciamento do ciclo de vida, planeje e projete o conteúdo, o que envolve o planejamento da solução e a tomada de decisões importantes que afetam sua abordagem ao gerenciamento do ciclo de vida. No segundo estágio, desenvolva o conteúdo e gerencie as alterações.

O gerenciamento de alterações de conteúdo durante seu ciclo de vida é importante para garantir a colaboração eficaz entre os criadores de conteúdo e a entrega estável e consistente de conteúdo aos consumidores.

A imagem a seguir mostra o ciclo de vida do conteúdo do Power BI, realçando o segundo estágio, em que você desenvolve o conteúdo e gerencia as alterações.

Observação

Para obter uma visão geral do gerenciamento do ciclo de vida do conteúdo, confira o primeiro artigo dessa série.

Dica

Este artigo se concentra nas principais decisões e considerações para lhe ajudar a desenvolver conteúdo e gerenciar alterações ao longo de seu ciclo de vida. Para obter mais diretrizes sobre como desenvolver conteúdo e gerenciar alterações, confira:

• O que é o gerenciamento do ciclo de vida no Microsoft Fabric?: este artigo fornece uma introdução técnica e um tutorial sobre a integração do Git do Fabric e os pipelines de implantação.
• Melhores práticas de gerenciamento do ciclo de vida: este artigo contém dicas e diretrizes práticas para usar os recursos de gerenciamento do ciclo de vida do Fabric e do Power BI para desenvolver conteúdo e gerenciar alterações.
• Integração do Power BI Desktop com o OneDrive e o SharePoint: este artigo contém uma visão geral das opções para usar e armazenar arquivos salvos no OneDrive corporativo ou de estudante ou no SharePoint ao executar o controle de versão com arquivos .pbix.
• Introdução ao Git no Azure Repos: esta série de artigos contém dicas práticas, tutoriais e diretrizes para realizar o controle do código-fonte usando um repositório Git no Azure Repos.

Os criadores e proprietários de conteúdo devem gerenciar as alterações no conteúdo 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 facilita a colaboração e o gerenciamento de conteúdo mais eficazes.

Outros benefícios do controle de versão incluem a capacidade de:

• Mesclar alterações de vários criadores de conteúdo e lidar com conflitos de mesclagem.
• Identificar qual conteúdo foi alterado e o que mudou nesse conteúdo.
• Vincular alterações de conteúdo a itens de trabalho específicos.
• Agrupar alterações em versões distintas com histórico de versão.
• Reverter alterações ou versões inteiras do conteúdo.

Dica

Recomendamos que você use o controle de versão para todo o conteúdo criado, sempre que possível. O uso do controle de versão traz benefícios significativos para criadores e consumidores de conteúdo, além de reduzir o risco de interrupção devido à perda de arquivos ou à incapacidade de reverter alterações.

A primeira etapa para configurar o controle de versão é decidir como você desenvolverá o conteúdo.

Decida como desenvolver o conteúdo

Dependendo de como você cria o conteúdo, você tomará decisões diferentes sobre como gerenciá-lo. Por exemplo, para relatórios e modelos semânticos do Power BI, um arquivo do Power BI Desktop (.pbix) tem menos opções de controle de versão em comparação com o formato do projeto do Power BI Desktop (.pbip). Isso ocorre porque um arquivo .pbix é um formato binário, enquanto o formato .pbip contém conteúdo e metadados legíveis por humanos baseados em texto. Ter conteúdo e metadados legíveis por humanos permite um acompanhamento mais fácil das alterações no modelo e no relatório usando o controle do código-fonte. O controle do código-fonte é quando você exibe e gerencia alterações dentro do conteúdo em seu código e metadados.

Dica

Ao desenvolver modelos semânticos e relatórios usando o Power BI Desktop, recomendamos que você use arquivos .pbip em vez de arquivos .pbix. Ao desenvolver modelos semânticos usando ferramentas XMLA, recomendamos que você use o formato TMDL (Tabular Model Definition Language), em vez de arquivos .bim.

Os formatos .pbip e TMDL dão suporte a um acompanhamento mais fácil e mesclagem de alterações no nível do objeto. Isso significa que você pode exibir e gerenciar alterações em objetos individuais, como medidas ou tabelas DAX.

Power BI Desktop

Você pode usar o Power BI Desktop para criar modelos semânticos ou relatórios, que podem ser salvos como arquivos .pbix ou .pbip. Há arquivos de conteúdo personalizado adicionais que você também pode utilizar ao usar o Power BI Desktop. Ao usar o Power BI Desktop para criar conteúdo, algumas decisões importantes que você deve tomar incluem:

• Qual formato de arquivo usar: você pode salvar o conteúdo como arquivos .pbix ou .pbip. Por exemplo, a integração do Git requer o uso de arquivos .pbip; os criadores de autoatendimento podem achar os arquivos .pbix mais simples de gerenciar e manter no Teams, no SharePoint ou no OneDrive.
• Como gerenciar o conteúdo personalizado: você pode adicionar temas, visuais personalizados ou imagens aos arquivos do Power BI Desktop, o que pode exigir considerações distintas para o gerenciamento do ciclo de vida. Por exemplo, quando os criadores de conteúdo fazem seus próprios visuais personalizados, eles devem salvar e gerenciar a definição visual em um arquivo separado.
• Como gerenciar versões prévias de recursos: você pode optar pelas versões prévias de recursos ou as configurações no Power BI Desktop, o que altera o conteúdo e como você o usará. Por exemplo, você pode executar etapas adicionais para validar o conteúdo que usa as versões prévias de recursos.

Criação na Web

Determinado conteúdo, como fluxos de dados, dashboards e scorecards, só pode ser criado no portal do Fabric. Você também pode criar ou modificar alguns conteúdos, como modelos semânticos, relatórios e relatórios paginados, tanto no portal do Fabric quanto usando ferramentas locais. Ao criar conteúdo usando a criação na Web, algumas decisões importantes que você deve tomar incluem:

• Como gerenciar alterações: você pode fazer alterações em vários tipos de itens usando a criação na Web, mas essas alterações podem ser salvas instantaneamente, substituindo as versões anteriores. Por exemplo, se estiver colaborando com outras pessoas, talvez seja melhor evitar a criação na Web de itens compartilhados, trabalhando em vez disso em sua própria cópia.
• Como recuperar backups de conteúdo: você pode criar conteúdo como relatórios ou modelos semânticos usando a criação na Web, mas esses itens não podem ser baixados para arquivos .pbix locais. Por exemplo, você pode optar por fazer backup desse conteúdo recuperando e armazenando seus metadados.

Dica

Ao desenvolver fluxos de dados e scorecards, recomendamos que você recupere as definições de item para gerenciar alterações e armazenar um backup. Você pode automatizar o fluxo de dados e a recuperação de scorecard usando as APIs REST do Fabric. Especificamente, você pode usar os pontos de extremidade Obter Fluxo de Dados e Obter Scorecards, respectivamente.

Cuidado

Alguns conteúdos, como dashboards, não têm a opção de recuperar uma definição. Para esse conteúdo, não é possível acompanhar facilmente as alterações ou recuperar um backup.

Outras ferramentas

Você pode usar outras ferramentas para criar ou gerenciar determinados tipos de conteúdo. Essas ferramentas podem fornecer benefícios adicionais, adequar-se melhor ao seu fluxo de trabalho ou ser necessárias para gerenciar recursos ou tipos de conteúdo específicos. Você pode usar outras ferramentas da Microsoft ou ferramentas de terceiros para criar e gerenciar conteúdo. Outras ferramentas que você pode usar para criar ou gerenciar conteúdo são as seguintes.

• Visual Studio ou Visual Studio Code: um ambiente de desenvolvimento integrado para os desenvolvedores criarem e gerenciarem modelos semânticos ou notebooks do Fabric. Com o Visual Studio e o Visual Studio Code, os desenvolvedores também podem executar o gerenciamento de controle do código-fonte (SCM), confirmando e efetuando push das alterações locais para um repositório remoto.
• Editor Tabular: uma ferramenta de terceiros para desenvolver e gerenciar modelos semânticos.
• Excel: uma ferramenta de cliente para tabelas dinâmicas e tabelas conectadas ao vivo que funcionam com um modelo semântico.
• Power BI Report Builder: um aplicativo da área de trabalho para criar arquivos de relatório paginado (.rdl).

Ao criar conteúdo usando outras ferramentas, algumas decisões importantes que você deve tomar incluem:

• Como gerenciar licenças: outras ferramentas podem exigir licenças adicionais que você deve gerenciar.
• Como publicar conteúdo: outras ferramentas podem exigir etapas adicionais para publicar conteúdo, como o uso de pontos de extremidade XMLA ou as APIs REST do Power BI.

Depois de decidir como criará o conteúdo, você precisará escolher onde publicará e testará o conteúdo enquanto o desenvolve.

Decida como você configurará e usará os workspaces

Ao desenvolver conteúdo, você deve usar vários workspaces (ou estágios) para separar o conteúdo de produção usado pela organização do conteúdo que está sendo desenvolvido ou validado. Há várias vantagens em usar workspaces separados para seu conteúdo:

• Você pode desenvolver e testar conteúdo sem afetar o conteúdo que está em uso no momento. Isso evita alterações que possam causar interrupções não intencionais no conteúdo em produção.
• Você pode usar recursos separados para desenvolver e testar o conteúdo, como o uso de gateways de dados separados ou capacidades do Fabric. Isso evita que os recursos usados para desenvolvimento e teste interrompam as cargas de trabalho de produção, causando lentidão na atualização de dados ou nos relatórios.
• Você pode criar um processo mais estruturado para desenvolver, testar e liberar conteúdo com ambientes discretos para cada um desses estágios. Isso ajudará você a melhorar a produtividade.

No Fabric e no Power BI, recomendamos que você use workspaces separados do Fabric, conforme descrito nos artigos de planejamento no nível do locatário e no nível do workspace.

Importante

Usar ambientes separados é uma etapa essencial para garantir o sucesso da abordagem de gerenciamento do ciclo de vida do conteúdo.

Há várias maneiras de usar workspaces do Fabric para separar ambientes. Normalmente, além do ambiente local, você usa dois ou mais workspaces para gerenciar o conteúdo durante seu ciclo de vida.

Responda às seguintes perguntas ao planejar como usará workspaces separados durante o ciclo de vida desse conteúdo:

• Quantos workspaces você precisa?
• Você separará os workspaces por tipo de item?
• Quem terá acesso a cada workspace?
• Os workspaces pertencerão a um pipeline de implantação do Fabric ou você orquestrará a implantação usando outras abordagens, como o uso do Azure Pipelines?
• Como você gerenciará a publicação entre workspaces? Por exemplo, você precisa garantir que os relatórios em um workspace de teste para relatórios se conectem a modelos semânticos em um workspace de teste separado para itens de dados?
• Você também precisa usar recursos de suporte separados para itens em workspaces de produção, como um cluster de gateway de dados local separado?

As seções a seguir fornecem uma visão geral de alto nível das diferentes abordagens que você pode adotar para separar workspaces para facilitar o gerenciamento do ciclo de vida.

Observação

As seções a seguir se concentram em como você pode configurar e usar workspaces separados. Você pode implantar conteúdo nesses workspaces usando uma das quatro abordagens a seguir:

• Publicação do Power BI Desktop.
• Implantação de conteúdo de outro workspace usando pipelines de implantação do Fabric.
• Sincronização de conteúdo de um repositório Git remoto usando a integração do Git.
• Implantação de conteúdo programaticamente usando as APIs REST do Fabric, APIs REST do Power BI ou pontos de extremidade XMLA.

Para obter mais informações sobre essas abordagens de implantação de conteúdo, confira Estágio 4: Implantar conteúdo, mais adiante nessa série.

Workspaces de teste e produção

Ao fornecer conteúdo mais simples que não é crítico para a organização, dois workspaces podem ser suficientes. Nesse cenário, os criadores de conteúdo normalmente têm colaboração limitada nos mesmos itens e desenvolvem conteúdo localmente.

O diagrama a seguir mostra um exemplo de alto nível de como você pode usar ambientes separados com apenas um workspace de teste e de produção.

O diagrama ilustra os seguintes processos e componentes para separar workspaces nessa abordagem.

Item	Descrição
	Os criadores de conteúdo desenvolvem conteúdo em seu ambiente local.
	Ao finalizar, os criadores de conteúdo publicarão o conteúdo em um workspace de teste. Os criadores de conteúdo podem desenvolver conteúdo que só pode ser produzido com a criação na Web e executar a validação do conteúdo no workspace de teste.
	Ao finalizar, os criadores de conteúdo implantarão o conteúdo em um workspace de produção. No workspace de produção, os criadores de conteúdo distribuirão conteúdo publicando um aplicativo do Power BI ou compartilhando conteúdo do workspace.

Observação

Há muitas maneiras diferentes de configurar e usar workspaces separados e implantar conteúdo entre esses workspaces. No entanto, recomendamos que você não execute o desenvolvimento local e, em seguida, publique o conteúdo diretamente em um workspace de produção. Isso pode levar a interrupções e erros evitáveis.

Workspaces de desenvolvimento, teste e produção

Ao fornecer conteúdo comercialmente crítico, você normalmente usará três ou mais workspaces separados. Nesse cenário, os criadores de conteúdo geralmente colaborarão em um workspace de desenvolvimento adicional que contém a versão mais recente da solução.

O diagrama a seguir ilustra um exemplo de alto nível de como você pode usar ambientes separados com um workspace de desenvolvimento, teste e produção.

O diagrama ilustra os seguintes processos e componentes para separar workspaces nessa abordagem.

Item	Descrição
	Os criadores de conteúdo desenvolvem conteúdo em seu ambiente local.
	Ao finalizar, os criadores de conteúdo publicarão o conteúdo em um workspace de desenvolvimento. No workspace de desenvolvimento, os criadores de conteúdo poderão desenvolver conteúdo que só pode ser produzido com a criação na Web. Os criadores de conteúdo também podem validar o conteúdo no workspace de desenvolvimento.
	Ao finalizar, os criadores de conteúdo implantarão conteúdo em um workspace de teste. No workspace de teste, os usuários validarão o conteúdo, seja no workspace ou em um aplicativo.
	Ao finalizar, os criadores de conteúdo implantarão o conteúdo em um workspace de produção. No workspace de produção, os criadores de conteúdo distribuirão conteúdo publicando um aplicativo do Power BI ou compartilhando conteúdo do workspace.

Observação

Você pode usar até dez ambientes diferentes com pipelines de implantação. Por exemplo, talvez você queira ter um ambiente de pré-produção entre o teste e a produção especificamente para tipos especiais de validação, como teste de desempenho.

Workspace privado com integração do Git

Ao fornecer conteúdo comercialmente crítico, cada desenvolvedor também pode usar seu próprio workspace privado para desenvolvimento. Nesse cenário, um workspace privado permite que os criadores de conteúdo testem conteúdo no portal do Fabric ou usem recursos como a atualização agendada sem correr o risco de interrupção para outras pessoas na equipe de desenvolvimento. Os criadores de conteúdo também podem desenvolver conteúdo no portal do Fabric aqui, como fluxos de dados. Os workspaces privados podem ser uma boa opção ao gerenciar alterações de conteúdo usando a integração do Git com o Azure DevOps.

Observação

O Azure DevOps é um conjunto de serviços que se integram ao Power BI e ao Fabric para lhe ajudar a planejar e orquestrar o gerenciamento do ciclo de vida do conteúdo. Ao usar o Azure DevOps dessa maneira, você normalmente aproveitará os seguintes serviços:

• Azure Repos: permite que você crie e use um repositório Git remoto, que é um local de armazenamento remoto que você usa para acompanhar e gerenciar alterações de conteúdo.
• Azure Pipelines: permite que você crie e use um conjunto de tarefas automatizadas para manipular, testar e implantar conteúdo de um repositório remoto em um workspace.
• Azure Test Plans: permite que você crie testes para validar a solução e automatizar o controle de qualidade junto com o Azure Pipelines.
• Azure Boards: permite que você use quadros para acompanhar tarefas e planos como itens de trabalho e vincular ou se referir a itens de trabalho de outros serviços do Azure DevOps.
• Azure Wiki: permite que você compartilhe informações com sua equipe para entender e contribuir com o conteúdo.

O diagrama a seguir mostra um exemplo de alto nível de como você pode usar ambientes separados usando um workspace privado com integração do Git.

Observação

O diagrama mostra desenvolvedores separados trabalhando em branches separados de uma solução (branch um e branch dois) antes de mesclar suas alterações em um branch principal. Essa é uma representação simplificada de uma estratégia de Git branch para ilustrar como os desenvolvedores podem integrar suas alterações a um repositório Git remoto e se beneficiar da integração do Git no Fabric.

O diagrama ilustra os seguintes processos e componentes para separar workspaces nessa abordagem.

Item	Descrição
	Cada criador de conteúdo desenvolverá conteúdo em seu próprio ambiente local.
	Ao finalizar, os criadores de conteúdo confirmarão e efetuarão push de suas alterações para um repositório remoto, como um repositório Git do Azure Repos.
	No repositório Git remoto, os criadores de conteúdo acompanharão e gerenciarão as alterações de conteúdo usando o controle do código-fonte, além de fazer branch e mesclar conteúdo para facilitar a colaboração.
	Os criadores de conteúdo sincronizam um branch do repositório remoto com um workspace privado. Após a sincronização, as alterações mais recentes que um criador confirma e efetua push para o branch ficarão visíveis nesse workspace privado. Diferentes criadores de conteúdo trabalham por conta própria, branches separados à medida que fazem alterações.
	Nos workspaces privados, os criadores de conteúdo podem desenvolver conteúdo usando a criação da Web e validar suas próprias alterações. Alterações no conteúdo feitas pela criação na Web podem ser sincronizadas com o branch no repositório Git quando o criador de conteúdo confirma e efetua push dessas alterações do workspace. Diferentes criadores de conteúdo trabalham em seus próprios workspaces privados e separados.
	Ao finalizar, os criadores de conteúdo executarão um pull request para mesclar suas alterações no branch principal da solução.
	Depois de mesclar as alterações, o branch principal é sincronizado com o workspace de desenvolvimento.
	No workspace de desenvolvimento, os criadores de conteúdo podem desenvolver conteúdo que não é compatível com a integração do Git do Fabric, como dashboards. Os criadores de conteúdo também validam a solução integrada que contém todas as alterações mais recentes.
	Ao finalizar, os criadores de conteúdo implantarão conteúdo em um workspace de teste. No workspace de teste, os usuários executam testes de aceitação do conteúdo pelo usuário.
	Ao finalizar, os criadores de conteúdo implantarão o conteúdo em um workspace de produção. No workspace de produção, os criadores de conteúdo distribuirão conteúdo publicando um aplicativo do Power BI ou compartilhando conteúdo do workspace.

Suporte a recursos para workspaces

Ao usar ambientes separados, você também deve considerar como isso afetará vários recursos de suporte que você usa nesses ambientes. Para esses recursos de suporte, considere se também é necessário separá-los no mesmo número de estágios ou como você coordenará o uso deles nesses ambientes.

• Gateways: considere o uso de clusters separados de gateway de dados local e gateways de VNet para cargas de trabalho de produção. Isso é benéfico para evitar interrupções, mas também para garantir o tempo de atividade quando você precisar atualizar esses gateways.
• Aplicativos: considere ter aplicativos separados para workspaces de teste e produção. Não é possível implantar ou copiar aplicativos entre estágios. Os aplicativos no workspace de teste destinam-se a lhe ajudar a testar o conteúdo e a experiência do aplicativo antes de implantar alterações no workspace de produção. Os aplicativos no workspace de produção destinam-se a fornecer conteúdo aos usuários finais em uma experiência estruturada.
• Azure DevOps: se você pretende usar o Azure DevOps para colaborar e orquestrar o controle do código-fonte e a implantação, considere como usará os branches e o Azure Pipelines para implantar conteúdo entre esses ambientes. Para obter mais informações sobre como usar o Azure Pipelines para implantar conteúdo, confira Estágio 4: Implantar conteúdo.

Depois de decidir como configurar e usar os workspaces, a próxima etapa é decidir como você executará o controle de versão para acompanhar e gerenciar as alterações de conteúdo.

Decida como você usará o controle de versão

No Power BI, você pode executar o controle de versão usando o SharePoint/OneDrive ou usando um repositório Git remoto, como o Azure Repos, que é um componente do Azure DevOps. Em ambas as abordagens, você adiciona arquivos de conteúdo local a um local de armazenamento remoto para ajudar a acompanhar e gerenciar alterações. Recomendamos que você use o SharePoint ou o OneDrive apenas para projetos menores e mais simples, pois eles não têm os recursos e a robustez para dar suporte a cenários maiores ou mais complicados.

Aqui estão algumas considerações gerais para lhe ajudar a configurar e usar o controle de versão.

• Alertas: você deve configurar alertas para quando outras pessoas adicionarem, removerem ou modificarem arquivos críticos.
• Escopo: defina claramente o escopo do local de armazenamento remoto. Idealmente, o escopo do local de armazenamento remoto deve ser idêntico ao escopo dos workspaces e aplicativos downstream que você usa para entregar conteúdo aos consumidores.
• Acesso: você deve configurar o acesso ao local de armazenamento remoto usando um modelo de permissões semelhante ao que você configurou para as permissões do pipeline de implantação e as funções do workspace. Os criadores de conteúdo precisam de acesso ao local de armazenamento remoto.
• Documentação: adicione arquivos de texto ao local de armazenamento remoto para descrever o local de armazenamento remoto e sua finalidade, propriedade, acesso e processos definidos.

As seções a seguir descrevem cada abordagem e as principais considerações para decidir qual delas você deve usar.

Controle de versão usando o SharePoint ou o OneDrive corporativo e de estudante

O SharePoint tem controle de versão interno para arquivos. Os criadores de conteúdo podem desenvolver modelos semânticos ou relatórios localmente, e suas alterações são sincronizadas com uma biblioteca de documentos do SharePoint ou do OneDrive corporativo e de estudante.

Dica

Use o SharePoint ou o OneDrive apenas para controle de versão em cenários menores e mais simples, como publicação de conteúdo de autoatendimento. Para cenários maiores ou mais complicados, você deve considerar a execução do controle do código-fonte usando um repositório Git remoto.

O diagrama a seguir ilustra uma visão geral de alto nível de como você executa o controle de versão usando o SharePoint ou o OneDrive.

O diagrama descreve os seguintes processos e componentes.

Item	Descrição
	Os criadores de conteúdo desenvolvem modelos semânticos e relatórios em seu ambiente local e salvam esses modelos e relatórios como arquivos .pbix.
	Ao finalizar, os criadores de conteúdo salvarão suas alterações, que serão sincronizadas em uma biblioteca remota do SharePoint ou do OneDrive corporativo ou de estudante.
	Na biblioteca remota, os criadores de conteúdo acompanham as alterações no nível do arquivo que facilitam o controle de versão.
	Os criadores de conteúdo podem vincular um modelo semântico publicado ou um relatório a um arquivo .pbix para facilitar a atualização do OneDrive. A atualização do OneDrive publica automaticamente alterações de conteúdo a cada hora.
	No workspace do Fabric, os criadores de conteúdo veem as alterações no conteúdo do Power BI após a conclusão da atualização do OneDrive.

Importante

Só é possível executar o controle de versão usando o SharePoint ou o OneDrive para arquivos do Power BI Desktop que contenham modelos semânticos ou relatórios. Não é possível executar facilmente o controle de versão usando o SharePoint ou o OneDrive para outros tipos de itens do Power BI, como fluxos de dados, ou para tipos de itens do Fabric, como notebooks. Para esses outros tipos de item, execute o controle de versão usando um repositório Git remoto, como o Azure Repos.

Para resumir, os criadores de conteúdo podem vincular um modelo semântico publicado ou um relatório a um arquivo .pbix armazenado em uma biblioteca do SharePoint ou do OneDrive corporativo e de estudante. Com essa abordagem, os criadores de conteúdo não precisam mais publicar o modelo semântico para ver as alterações. Em vez disso, as alterações ficam visíveis após uma atualização do OneDrive automática, que ocorre a cada hora. Embora conveniente, essa abordagem traz algumas considerações e não pode ser facilmente revertida.

Embora seja fácil de configurar e gerenciar, o controle de versão com o SharePoint ou o OneDrive tem mais limitações. Por exemplo, não é possível exibir alterações no conteúdo e também não é possível comparar versões. Além disso, não é possível configurar processos mais sofisticados para gerenciar essas alterações (como branches ou pull requests, descritas mais adiante neste artigo).

Considere usar o SharePoint ou o OneDrive para acompanhar e gerenciar alterações nos seguintes cenários:

• O conteúdo consiste apenas em modelos semânticos ou relatórios salvos como arquivos .pbix.
• Os usuários de autoatendimento criam e gerenciam o conteúdo.
• Os criadores de conteúdo colaboram usando o Microsoft Teams.
• Os criadores de conteúdo não têm experiência com o Git e o gerenciamento de controle do código-fonte.
• Os criadores de conteúdo gerenciam um único item com complexidade e colaboração limitadas.
• Os arquivos .pbix têm um rótulo de confidencialidade aplicado que criptografa seu conteúdo.

Observação

O OneDrive e o SharePoint dão suporte ao conteúdo com rótulos de confidencialidade aplicados, exceto em alguns cenários limitados. Por outro lado, a integração do Git do Fabric não dá suporte a rótulos de confidencialidade.

Evite usar o SharePoint ou o OneDrive para controlar e gerenciar alterações nos seguintes cenários:

• O conteúdo consiste em tipos de item diferentes de modelos semânticos e relatórios.
• O conteúdo é complexo ou grande no escopo.
• Os criadores de conteúdo precisam trabalhar de forma colaborativa no mesmo item ao mesmo tempo.

As seções a seguir descrevem considerações adicionais para usar efetivamente o controle de versão usando o SharePoint ou o OneDrive com o Power BI.

Integração do Microsoft Teams

Você pode usar as bibliotecas de documentos do Microsoft Teams se os criadores de conteúdo o utilizarem para colaboração. As bibliotecas de documentos são sites do SharePoint, e o uso das bibliotecas de documentos (em vez de um site separado do SharePoint ou uma pasta do OneDrive) garante a centralização de conteúdo, arquivos e colaboração.

Fazer check-in e check-out de arquivos

Você deve fazer check-out de arquivos nos quais está trabalhando para evitar possíveis conflitos de alteração. Depois que as alterações forem concluídas, faça o check-in dos arquivos com comentários que descrevem a alteração. Os arquivos de check-in e de check-out ajudam você a melhorar a colaboração entre criadores de conteúdo ao usar o SharePoint ou o OneDrive corporativo e de estudante para controle de versão. Se você fizer check-in e check-out de arquivos com vários criadores de conteúdo, poderá modificar a biblioteca do site do SharePoint para exibir a última atualização e os comentários do último check-in.

Histórico de versão

Verifique se você faz backup do conteúdo em um local separado em caso de interrupções inesperadas na biblioteca de documentos do site do SharePoint. Você também deve definir limites para o número de versões mantidas no site do SharePoint e excluir versões antigas. Isso garante que o histórico de versões permaneça significativo e não assuma muito espaço.

Para um controle de versão mais sofisticado, você pode armazenar arquivos em um repositório remoto como o Azure Repos e gerenciar alterações usando o controle do código-fonte.

Controle do código-fonte usando um repositório Git remoto

Um repositório Git remoto facilita o controle do código-fonte dos arquivos, o que permite aos criadores de conteúdo mais opções para controlar e gerenciar alterações. Resumindo, os criadores de conteúdo podem desenvolver conteúdo localmente ou no serviço do Power BI, em seguida, confirmar e efetuar push dessas alterações para um repositório Git remoto, como o Azure Repos

Observação

Você também pode executar o controle do código-fonte do conteúdo sem usar a integração do Git. Nesse cenário, você ainda controla e gerencia alterações de conteúdo em um repositório Git remoto, mas implanta conteúdo usando as APIs REST ou pontos de extremidade de leitura/gravação XMLA. Para obter mais informações sobre esses métodos de implantação de conteúdo, confira Estágio 4: Implantar conteúdo.

O diagrama a seguir ilustra uma visão geral de alto nível de como executar o controle do código-fonte

O diagrama descreve os seguintes processos e componentes.

Item	Descrição
	Os criadores de conteúdo desenvolvem modelos semânticos e relatórios em seu ambiente local e salvam esses modelos e relatórios como arquivos .pbip. Os criadores de conteúdo também podem desenvolver modelos semânticos e salvar metadados de modelo.
	Ao finalizar, os criadores de conteúdo salvarão suas alterações, que serão confirmadas e efetuadas push para um repositório Git remoto em intervalos regulares.
	No repositório Git remoto, os criadores de conteúdo acompanham as alterações no nível do objeto, o que facilita o controle de versão. Os criadores de conteúdo também podem criar branches para trabalhar no conteúdo e mesclar suas alterações em um único branch usando pull requests.
	Os criadores de conteúdo podem sincronizar o conteúdo do repositório remoto usando a integração do Git. Eles também podem implantar conteúdo usando outras abordagens, como o Azure Pipelines, juntamente com as APIs REST.
	No workspace do Fabric, os criadores de conteúdo veem as alterações no conteúdo do Power BI após a conclusão da sincronização ou implantação. Os criadores de conteúdo podem criar conteúdo como fluxos de dados ou notebooks no workspace. Se eles usarem a integração do Git, os criadores de conteúdo vincularão esse workspace a um branch específico do repositório remoto.
	Os criadores de conteúdo podem confirmar e efetuar push das alterações de um workspace para o repositório remoto usando a integração do Git. Essas alterações podem importar definições de item para conteúdo com suporte criado no workspace, como fluxos de dados e notebooks.

Em resumo, os criadores de conteúdo armazenam arquivos .pbip, arquivos de metadados e documentação em um repositório remoto central do 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 fornece opções mais sofisticadas para acompanhar e gerenciar alterações em comparação com o SharePoint e o OneDrive. Manter um repositório bem coletado e documentado é essencial porque é a base de todo o conteúdo e colaboração.

Considere usar o controle do código-fonte para acompanhar e gerenciar alterações nos seguintes cenários:

• Equipes centralizadas ou descentralizadas criam e gerenciam o conteúdo.
• Os criadores de conteúdo colaboram usando o Azure DevOps.
• Os criadores de conteúdo estão familiarizados com o Git, o gerenciamento de controle do código-fonte ou os princípios do DataOps.
• Os criadores de conteúdo gerenciam conteúdo complexo ou importante ou esperam que o conteúdo seja escalado e cresça em complexidade e importância.

Aqui estão alguns pré-requisitos e considerações para lhe ajudar a usar efetivamente o controle do código-fonte com o Azure DevOps.

• Git: para confirmar e efetuar push das alterações para um repositório remoto, os criadores de conteúdo precisam baixar e instalar o Git. 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?.
• Ferramentas: para usar o Git, os criadores de conteúdo precisam usar uma interface de linha de comando (CLI) ou um cliente de interface gráfica do usuário (GUI) para SCM, como o Visual Studio ou o Visual Studio Code.
• Licenças e permissões: para criar e usar um repositório Git do Azure Repos, os criadores de conteúdo devem ter o seguinte:
  • Nível de acesso definido como Básico (em oposição ao Stakeholder).
  • Pertença a uma organização e a um projeto.
  • Permissões de repositório apropriadas.
• Integração do Git do Fabric: para sincronizar o conteúdo em um repositório remoto com um workspace do Microsoft Fabric, os criadores de conteúdo usam a integração do Git do Fabric. Isso é importante para acompanhar e gerenciar alterações no conteúdo criado no portal do Fabric, como fluxos de dados.

Dica

Para facilitar o controle do código-fonte com o desenvolvimento local, recomendamos usar um aplicativo cliente como o Visual Studio Code. Use o Power BI Desktop para desenvolver conteúdo e, em seguida, poderá usar o Visual Studio Code para executar o gerenciamento de controle do código-fonte desse conteúdo, preparando, confirmando e efetuando push das alterações para o repositório remoto.

Aviso

A integração do Git do Fabric tem algumas limitações com os itens e cenários com suporte. Certifique-se de validar primeiro se a integração do Git do Fabric é a mais adequada ao cenário específico ou se você deve adotar uma abordagem diferente para implementar o controle do código-fonte.

Além disso, os rótulos de confidencialidade não são compatíveis com a integração do Git do Fabric e a exportação de itens com rótulos de confidencialidade pode ser desabilitada. Se o conteúdo tiver rótulos de confidencialidade, você deverá planejar como conseguir o controle de versão enquanto ainda respeita suas políticas de prevenção contra perda de dados.

Um dos principais benefícios do uso do controle do código-fonte com o Azure Repos é a colaboração aprimorada entre criadores de conteúdo e mais personalização e supervisão em relação a alterações de conteúdo e implantação.

O diagrama a seguir ilustra uma visão geral de alto nível de como o Azure DevOps habilita a colaboração com o controle do código-fonte.

Observação

O diagrama anterior ilustra um exemplo de como colaborar usando o Azure DevOps. Escolha uma abordagem que melhor atenda às necessidades e à maneira de trabalhar de sua equipe.

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.

As seções a seguir descrevem considerações adicionais para usar efetivamente o controle do código-fonte usando o Azure DevOps e o Power BI.

Importante

O uso efetivo de branches, confirmações, pull requests e mesclagens é essencial para se beneficiar mais do controle do código-fonte ao gerenciar o ciclo de vida do conteúdo do Power BI.

Usar branches

Para elaborar, os criadores de conteúdo colaboram usando uma estratégia de branch. Uma estratégia de ramificação permite que criadores de conteúdo individuais trabalhem 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 efetuado push 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.

Ao usar uma estratégia de branches para gerenciar o conteúdo do Fabric, considere os seguintes fatores.

• Qual branch os criadores de conteúdo devem clonar para seu próprio trabalho. Por exemplo, se esses branches forem um clone do branch principal (conhecido como desenvolvimento baseado em tronco) ou se forem outros branches, como branches de lançamento para versões específicas e planejadas de conteúdo.
• Se você for definir o escopo de um trabalho específico para versões de conteúdo distintas usando branches de versão.
• Quais branches se conectam a qual workspace quando você usa a integração do Git do Fabric.

Dica

Confira Adotar uma estratégia de Git branch para obter diretrizes e recomendações específicas sobre como usar melhor uma estratégia de branch para facilitar efetivamente a colaboração.

Alterações em lote em confirmações

Durante o desenvolvimento de conteúdo, os criadores devem preparar regularmente alterações em lotes (ou grupos). Essas alterações devem abordar um item de trabalho específico para a solução (como um recurso ou um problema). Ao finalizar, os criadores de conteúdo confirmarão essas alterações em etapas.

As alterações em lote dessa maneira têm vários benefícios.

• Isso ajuda a estruturar o desenvolvimento e dá aos criadores de conteúdo a chance de revisar e documentar as alterações que eles agruparam.
• Isso melhora o alinhamento entre planejamento e desenvolvimento, facilitando a vinculação de recursos e problemas e obter transparência sobre como o trabalho está sendo feito.
• Os proprietários técnicos poderão examinar com mais facilidade os pull requests dos criadores de conteúdo se as alterações forem enviadas em lote adequadamente e tiverem mensagens de confirmação claras.

Ao preparar e confirmar alterações no conteúdo do Power BI, considere os seguintes fatores.

• Se você vai preparar e confirmar alterações de um repositório local ou do workspace do Fabric.
• Coloque arquivos .pbip em pastas de nível superior ao armazenar vários modelos ou relatórios em um único repositório. Isso facilitará a identificação e o agrupamento de alterações feitas por você.
• Ignore alterações de metadados inócuas ou inúteis usando um arquivo gitignore ou um arquivo .gitattributes. Isso garantirá que todas as alterações confirmadas sejam significativas.

Dica

Confira Salvar seu trabalho com confirmações para obter diretrizes e recomendações específicas sobre como preparar e confirmar seu trabalho em um repositório Git.

Criar pull requests para mesclar alterações

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.

Ao usar pull requests para mesclar alterações no conteúdo do Power BI, considere os fatores a seguir.

• Quais padrões e práticas você usará para executar sua revisão, se houver. Por exemplo, você pode usar regras do Analisador de Melhores Práticas para modelos semânticos.
• Como você revisará as alterações nos metadados do relatório, que não são fáceis de ler e entender sem o uso de ferramentas de terceiros.
• Como você abordará e resolverá conflitos de mesclagem.

Dica

Confira Sobre pull requests e Estratégias de mesclagem e mesclagem squash para obter diretrizes e recomendações específicas sobre como usar melhor pull requests para facilitar a colaboração mesclando alterações no conteúdo.

Lista de verificação – ao planejar onde você armazenará arquivos, as principais decisões e ações incluem:

• Escolha suas ferramentas de desenvolvimento: verifique se sua abordagem para desenvolver conteúdo está alinhada com a forma como você colaborará com outros criadores de conteúdo e usará o controle de versão.
• Escolha entre os formatos .pbip e .pbix para modelos e relatórios: normalmente, o formato .pbip é mais benéfico para o controle do código-fonte, mas os usuários de autoatendimento podem achar arquivos .pbix mais fáceis de usar.
• Modelo semântico separado e desenvolvimento de relatório: o controle de versão é mais eficaz quando você gerencia alterações para diferentes tipos de item, separadamente. Separar o modelo e o desenvolvimento de relatórios é considerado uma boa prática.
• Decida quantos workspaces você precisa: o uso de ambientes separados é fundamental para o sucesso do gerenciamento do ciclo de vida do conteúdo. Verifique se você esclareceu quantos workspaces você precisa e realize o planejamento no nível do workspace apropriado.
• Decida como implementará o controle de versão: decida entre uma abordagem mais simples usando o SharePoint ou o OneDrive corporativo ou usando o Azure DevOps para facilitar o controle do código-fonte.
• Configure seu repositório remoto: crie um espaço estruturado na pasta do OneDrive ou no Repositório Git em que você armazenará conteúdo para controlar e gerenciar alterações.
• Se você estiver usando o controle do código-fonte, configure arquivos .gitignore e .gitattributes: certifique-se de configurar seu repositório para que você esteja apenas acompanhando alterações significativas.
• Se você estiver usando o controle do código-fonte, defina estratégias de ramificação e mesclagem: certifique-se de definir processos claros de como você configurará e usará o controle do código-fonte para dar melhor suporte ao desenvolvimento. Evite complicar demais o processo. Em vez disso, tente complementar a maneira atual de trabalhar em suas equipes de desenvolvimento.

Conteúdo relacionado

No próximo artigo dessa série, saiba como validar o conteúdo como parte do gerenciamento do ciclo de vida do conteúdo.