Partilhar via


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

Nota

Este artigo faz parte da série de artigos de planejamento de implementação do Power BI. Esta série se concentra principalmente na experiência do Power BI no Microsoft Fabric. Para obter uma introdução à série, consulte Planejamento de implementação do Power BI.

Este artigo ajuda você a desenvolver conteúdo e gerenciar alterações como parte do gerenciamento do ciclo de vida do conteúdo. Destina-se principalmente a:

  • Equipes do Centro de Excelência (COE) 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 ao gerenciamento do ciclo de vida com eficiência.
  • Criadores de conteúdo e proprietários de conteúdo: usuários que criam conteúdo, que desejam 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 criam.

O gerenciamento do ciclo de vida é 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, você planeja e projeta conteúdo, o que envolve o planejamento da solução e a tomada de decisões-chave que afetam sua abordagem ao gerenciamento do ciclo de vida. Na segunda etapa, você desenvolve conteúdo e gerencia mudanças.

Gerenciar as alterações de conteúdo durante seu ciclo de vida é importante para garantir uma colaboração eficaz entre os criadores de conteúdo e uma 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, destacando o estágio dois, onde você desenvolve conteúdo e gerencia alterações.

O diagrama mostra o ciclo de vida do conteúdo do Power BI. A etapa 2, que trata do desenvolvimento de conteúdo e do gerenciamento de mudanças, é destacada.

Nota

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

Gorjeta

Este artigo se concentra nas principais decisões e considerações para ajudá-lo a desenvolver conteúdo e gerenciar alterações ao longo de seu ciclo de vida. Para obter mais orientações sobre como desenvolver conteúdo e gerenciar alterações, consulte:

  • O que é o gerenciamento do ciclo de vida no Microsoft Fabric?: Este artigo fornece uma introdução técnica e um tutorial para os pipelines de integração e implantação do Fabric Git.
  • Práticas recomendadas de gerenciamento de ciclo de vida: este artigo contém dicas práticas e orientações para usar os recursos de gerenciamento de 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 for Work and School ou no SharePoint quando você executa 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 orientações para executar 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 de conteúdo 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 facilita uma colaboração e uma gestão de conteúdos mais eficazes.

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

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

Gorjeta

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 tem benefícios significativos para criadores de conteúdo e consumidores e reduz 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 conteúdo

Dependendo de como você cria 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 para controle de versão em comparação com o formato de 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 de alterações de modelo e relatório usando o controle do código-fonte. O controle do código-fonte é quando você visualiza e gerencia alterações no conteúdo de seu código e metadados.

Gorjeta

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 suportam rastreamento e mesclagem mais fáceis 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 personalizados adicionais que você também pode usar 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 que você use arquivos .pbip, os criadores de autoatendimento podem achar os arquivos .pbix mais simples de gerenciar e manter no Teams, SharePoint ou OneDrive.
  • Como gerenciar 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 criam seus próprios visuais personalizados, eles devem salvar e gerenciar a definição visual em um arquivo separado.
  • Como gerenciar recursos de visualização: você pode optar por visualizar recursos ou 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 recursos de visualização.

Criação na Web

Determinados conteúdos, como fluxos de dados, painéis e scorecards, só podem ser criados no portal do Fabric. Você também pode criar ou modificar algum conteúdo, como modelos semânticos, relatórios e relatórios paginados, no portal do Fabric ou 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 muitos tipos de item usando a criação na Web, mas essas alterações podem ser salvas instantaneamente, substituindo versões anteriores. Por exemplo, se você estiver colaborando com outras pessoas, convém evitar a criação na Web em 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.

Gorjeta

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 da malha. Especificamente, você pode usar os pontos de extremidade Get Dataflow e Get Scorecards , respectivamente.

Atenção

Alguns conteúdos, como painéis, não têm a opção de recuperar uma definição. Para esse conteúdo, você não pode controlar facilmente as alterações ou recuperar um backup.

Outras ferramentas

Você pode usar outras ferramentas para criar ou gerenciar certos tipos de conteúdo. Essas ferramentas podem fornecer benefícios adicionais, se adequar 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 desenvolvedores criarem e gerenciarem modelos semânticos ou blocos de anotações de malha. 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 enviando alterações locais para um repositório remoto.
  • Editor de tabelas: uma ferramenta de terceiros para desenvolver e gerenciar modelos semânticos.
  • Excel: Uma ferramenta de cliente para tabelas dinâmicas e tabelas conectadas em tempo real que funcionam com um modelo semântico.
  • Construtor de Relatórios do Power BI: um aplicativo de á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 usar pontos de extremidade XMLA ou as APIs REST do Power BI.

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

Decida como você configurará e usará os espaços de trabalho

Ao desenvolver conteúdo, você deve usar vários espaços de trabalho (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 espaços de trabalho separados para o 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 podem causar interrupções não intencionais no conteúdo em produção.
  • Você pode usar recursos separados para desenvolver e testar conteúdo, como usar gateways de dados separados ou capacidades de malha. Isso evita que os recursos usados para desenvolvimento e teste interrompam as cargas de trabalho de produção, causando atualizações de dados ou relatórios lentos.
  • Você pode criar um processo mais estruturado para desenvolver, testar e liberar conteúdo tendo ambientes discretos para cada um desses estágios. Isto ajuda-o a melhorar a produtividade.

No Fabric e no Power BI, recomendamos que você use espaços de trabalho de malha separados, conforme descrito nos artigos de planejamento no nível do locatário e no nível do espaço de trabalho.

Importante

O uso de ambientes separados é uma etapa essencial para garantir o sucesso de sua abordagem de gerenciamento do ciclo de vida do conteúdo.

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

Responda às seguintes perguntas ao planejar como usará espaços de trabalho separados ao longo do ciclo de vida desse conteúdo:

  • De quantos espaços de trabalho precisa?
  • Você separará os espaços de trabalho por tipo de item?
  • Quem terá acesso a cada espaço de trabalho?
  • Os espaços de trabalho 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 espaços de trabalho? Por exemplo, você precisa garantir que os relatórios em um espaço de trabalho de teste para relatórios se conectem a modelos semânticos em um espaço de trabalho de teste separado para itens de dados?
  • Você também precisa usar recursos de suporte separados para itens em espaços de trabalho 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 espaços de trabalho separados para facilitar o gerenciamento do ciclo de vida.

Nota

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

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

Para obter mais informações sobre essas abordagens para implantar conteúdo, consulte Estágio 4: implantar conteúdo posteriormente nesta série.

Espaços de trabalho de teste e produção

Quando você fornece conteúdo mais simples que não é crítico para a organização, dois espaços de trabalho geralmente 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 espaço de trabalho de teste e produção.

O diagrama mostra a abordagem 1, que é sobre espaços de trabalho de teste e produção. Os itens no diagrama são descritos na tabela a seguir.

O diagrama descreve os seguintes processos e componentes para separar espaços de trabalho nesta abordagem.

Item Descrição
Ponto 1. Os criadores de conteúdo desenvolvem conteúdo em seu ambiente local.
Ponto 2. Quando prontos, os criadores de conteúdo publicam conteúdo em um espaço de trabalho de teste. Os criadores de conteúdo podem desenvolver conteúdo que só pode ser produzido com autoria na Web e executar a validação de conteúdo no espaço de trabalho de teste.
Ponto 3. Quando prontos, os criadores de conteúdo implantam o conteúdo em um espaço de trabalho de produção. No espaço de trabalho de produção, os criadores de conteúdo distribuem conteúdo publicando um aplicativo do Power BI ou compartilhando conteúdo do espaço de trabalho.

Nota

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

Espaços de trabalho de desenvolvimento, teste e produção

Ao fornecer conteúdo essencial para os negócios, você normalmente usa três ou mais espaços de trabalho separados. Nesse cenário, os criadores de conteúdo geralmente colaboram em um espaço de trabalho de desenvolvimento adicional que contém a versão mais recente da solução.

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

Diagrama que mostra a abordagem 2: espaços de trabalho de desenvolvimento, teste e produção.

O diagrama descreve os seguintes processos e componentes para separar espaços de trabalho nesta abordagem.

Item Descrição
Ponto 1. Os criadores de conteúdo desenvolvem conteúdo em seu ambiente local.
Ponto 2. Quando prontos, os criadores de conteúdo publicam conteúdo em um espaço de trabalho de desenvolvimento. No espaço de trabalho de desenvolvimento, os criadores de conteúdo podem desenvolver conteúdo que só pode ser produzido com autoria na Web. Os criadores de conteúdo também podem validar o conteúdo no espaço de trabalho de desenvolvimento.
Ponto 3. Quando prontos, os criadores de conteúdo implantam o conteúdo em um espaço de trabalho de teste. No espaço de trabalho de teste, os usuários validam o conteúdo, seja no espaço de trabalho ou em um aplicativo.
Ponto 4. Quando prontos, os criadores de conteúdo implantam o conteúdo em um espaço de trabalho de produção. No espaço de trabalho de produção, os criadores de conteúdo distribuem conteúdo publicando um aplicativo do Power BI ou compartilhando conteúdo do espaço de trabalho.

Nota

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

Espaço de trabalho privado com integração Git

Ao fornecer conteúdo essencial para os negócios, cada desenvolvedor também pode usar seu próprio espaço de trabalho privado para desenvolvimento. Nesse cenário, um espaço de trabalho privado permite que os criadores de conteúdo testem o conteúdo no portal do Fabric ou usem recursos como a atualização agendada sem correr o risco de interromper outras pessoas da equipe de desenvolvimento. Os criadores de conteúdo também podem desenvolver conteúdo no portal do Fabric aqui, como fluxos de dados. Os espaços de trabalho privados podem ser uma boa opção quando você está gerenciando alterações de conteúdo usando a integração do Git junto com o Azure DevOps.

Nota

O Azure DevOps é um conjunto de serviços que se integra ao Power BI e ao Fabric para ajudá-lo a planejar e orquestrar o gerenciamento do ciclo de vida do conteúdo. Quando você usa o Azure DevOps dessa maneira, normalmente aproveita os seguintes serviços:

  • Azure Repos: Permite criar e usar um repositório Git remoto, que é um local de armazenamento remoto que você usa para controlar e gerenciar alterações de conteúdo.
  • Azure Pipelines: Permite criar e usar um conjunto de tarefas automatizadas para manipular, testar e implantar conteúdo de um repositório remoto em um espaço de trabalho.
  • Planos de Teste do Azure: Permite projetar 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 controlar tarefas e planos como itens de trabalho e vincular ou fazer referência a itens de trabalho de outros serviços de DevOps do Azure.
  • 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 espaço de trabalho privado com integração Git.

Diagrama que mostra a abordagem 3: Espaços de trabalho privados com integração Git.

Nota

O diagrama mostra desenvolvedores separados trabalhando em ramificações separadas de uma solução (ramificação um e ramificação dois) antes de mesclar suas alterações em uma ramificação principal. Esta é uma representação simplificada de uma estratégia de ramificação do Git 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 descreve os seguintes processos e componentes para separar espaços de trabalho nesta abordagem.

Item Descrição
Ponto 1. Cada criador de conteúdo desenvolve conteúdo em seu próprio ambiente local.
Ponto 2. Quando estiverem prontos, os criadores de conteúdo confirmam e enviam suas alterações por push para um repositório remoto, como um repositório Git do Azure Repos.
Ponto 3. No repositório Git remoto, os criadores de conteúdo rastreiam e gerenciam as alterações de conteúdo usando o controle do código-fonte e ramificam e mesclam conteúdo para facilitar a colaboração.
Ponto 4. Os criadores de conteúdo sincronizam uma ramificação do repositório remoto com um espaço de trabalho privado. Após a sincronização, as alterações mais recentes que um criador confirma e envia por push para a ramificação ficam visíveis nesse espaço de trabalho privado. Diferentes criadores de conteúdo trabalham por conta própria, ramificações separadas à medida que fazem alterações.
Ponto 5. Nos espaços de trabalho privados, os criadores de conteúdo podem desenvolver conteúdo usando a criação na Web e validar suas próprias alterações. As alterações no conteúdo feitas pela criação na Web podem ser sincronizadas com a ramificação no repositório Git quando o criador de conteúdo confirma e envia essas alterações do espaço de trabalho. Diferentes criadores de conteúdo trabalham em seus próprios espaços de trabalho privados separados.
Ponto 6. Quando prontos, os criadores de conteúdo executam uma solicitação pull para mesclar suas alterações na ramificação principal da solução.
Ponto 7. Depois de mesclar as alterações, a ramificação principal é sincronizada com o espaço de trabalho de desenvolvimento.
Ponto 8. No espaço de trabalho de desenvolvimento, os criadores de conteúdo podem desenvolver conteúdo que não é suportado pela integração do Fabric Git, como painéis. Os criadores de conteúdo também validam a solução integrada que contém todas as alterações mais recentes.
Ponto 9. Quando prontos, os criadores de conteúdo implantam o conteúdo em um espaço de trabalho de teste. No espaço de trabalho de teste, os usuários executam testes de aceitação do conteúdo pelo usuário.
Ponto 10. Quando prontos, os criadores de conteúdo implantam o conteúdo em um espaço de trabalho de produção. No espaço de trabalho de produção, os criadores de conteúdo distribuem conteúdo publicando um aplicativo do Power BI ou compartilhando conteúdo do espaço de trabalho.

Recursos de suporte para espaços de trabalho

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 você também precisa separá-los no mesmo número de estágios ou como coordenará seu uso nesses ambientes.

  • Gateways: considere o uso de clusters de gateway de dados locais separados e gateways 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 espaços de trabalho de teste e produção. Não é possível implantar ou copiar aplicativos entre estágios. Os aplicativos no espaço de trabalho de teste destinam-se a ajudá-lo a testar o conteúdo e a experiência do aplicativo antes de implantar alterações no espaço de trabalho de produção. Os aplicativos no espaço de trabalho de produção destinam-se a fornecer conteúdo aos usuários finais de forma estruturada e com experiência.
  • Azure DevOps: Se você pretende usar o Azure DevOps para colaborar e orquestrar o controle e a implantação do código-fonte, considere como você usará ramificações e Pipelines do Azure para implantar conteúdo entre esses ambientes. Para obter mais informações sobre como usar o Azure Pipelines para implantar conteúdo, consulte Estágio 4: Implantar conteúdo.

Depois de decidir como você configurará e usará os espaços de trabalho, a próxima etapa é decidir como você executará o controle de versão para controlar 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 controlar e gerenciar alterações. Recomendamos que você use o SharePoint ou o OneDrive apenas para projetos menores e mais simples, pois ele não tem os recursos e a robustez para suportar cenários maiores ou mais complicados.

Aqui estão algumas considerações gerais para ajudá-lo 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 é 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 local de armazenamento remoto 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 ter 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 for Work and School

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 for Work and School.

Gorjeta

Use o SharePoint ou o OneDrive apenas para controle de versão em cenários mais simples e menores, 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 mostra uma visão geral de alto nível de como você executa o controle de versão usando o SharePoint ou o OneDrive.

Diagrama que mostra a abordagem 1: Controle de versão usando o SharePoint ou o OneDrive.

O diagrama descreve os seguintes processos e componentes.

Item Descrição
Ponto 1. 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.
Ponto 2. Quando estiverem prontos, os criadores de conteúdo salvam suas alterações, que sincronizam com uma biblioteca remota do SharePoint ou do OneDrive for Work and School.
Ponto 3. Na biblioteca remota, os criadores de conteúdo controlam as alterações no nível do arquivo, o que facilita o controle de versão.
Ponto 4. Os criadores de conteúdo podem vincular um modelo semântico publicado ou relatório a um arquivo .pbix para facilitar a atualização do OneDrive. A atualização do OneDrive publica automaticamente as alterações de conteúdo a cada hora.
Ponto 5. No espaço de trabalho Malha, 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

Você só pode executar o controle de versão usando arquivos do SharePoint ou do OneDrive para Power BI Desktop que contenham modelos semânticos ou relatórios. Você não pode executar facilmente o controle de versão usando o SharePoint ou o OneDrive para outros tipos de item do Power BI, como fluxos de dados, ou para tipos de item de malha, como blocos de anotações. Para esses outros tipos de item, você deve executar 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 ou relatório publicado a um arquivo .pbix armazenado em uma biblioteca do SharePoint ou do OneDrive for Work and School. 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 automática do OneDrive, que ocorre de hora em hora. Embora conveniente, essa abordagem vem com 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 visualizar 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 ramificações ou solicitações pull, descritas mais adiante neste artigo).

Considere usar o SharePoint ou o OneDrive para controlar 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 são inexperientes 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 ficheiros .pbix têm uma etiqueta de sensibilidade aplicada que encripta o seu conteúdo.

Nota

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

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 de grande alcance.
  • 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 com o Microsoft Teams

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

Ficheiros de check-in e check-out

Você deve fazer check-out dos arquivos nos quais está trabalhando para evitar possíveis conflitos de alteração. Quando as alterações estiverem concluídas, faça check-in dos arquivos com comentários que descrevam a alteração. O check-in e check-out de arquivos ajuda você a melhorar a colaboração entre criadores de conteúdo quando você usa o SharePoint ou o OneDrive for Work and School 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 de sites do SharePoint para exibir a última atualização e os comentários do último check-in.

Histórico de versões

Certifique-se de fazer 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 ocupe 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 rastrear e gerenciar alterações. Em resumo, os criadores de conteúdo podem desenvolver conteúdo localmente ou no serviço do Power BI e, em seguida, confirmar e enviar essas alterações por push para um repositório Git remoto, como o Azure Repos

Nota

Você também pode executar o controle do código-fonte do seu conteúdo sem usar a integração com o 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, consulte Estágio 4: Implantar conteúdo.

O diagrama a seguir mostra uma visão geral de alto nível de como você executa o controle do código-fonte por

Diagrama que mostra a abordagem 2: Controle do código-fonte usando o Azure DevOps.

O diagrama descreve os seguintes processos e componentes.

Item Descrição
Ponto 1. 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 modelos.
Ponto 2. Quando prontos, os criadores de conteúdo salvam suas alterações, que eles confirmam e enviam por push para um repositório Git remoto em intervalos regulares.
Ponto 3. No repositório Git remoto, os criadores de conteúdo rastreiam 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 ramificações para trabalhar no conteúdo e mesclar suas alterações em uma única ramificação usando solicitações pull.
Ponto 4. Os criadores de conteúdo podem sincronizar conteúdo do repositório remoto usando a integração Git. Eles também podem implantar conteúdo usando outras abordagens, como Pipelines do Azure junto com as APIs REST.
Ponto 5. No espaço de trabalho Malha, os criadores de conteúdo veem as alterações no conteúdo do Power BI após a conclusão da sincronização ou da implantação. Os criadores de conteúdo podem criar conteúdo como fluxos de dados ou blocos de anotações no espaço de trabalho. Se usarem a integração com o Git, os criadores de conteúdo vincularão esse espaço de trabalho a uma ramificação específica do repositório remoto.
Ponto 6. Os criadores de conteúdo podem confirmar e enviar alterações de um espaço de trabalho para o repositório remoto usando a integração Git. Essas alterações podem importar definições de item para conteúdo suportado criado no espaço de trabalho, como fluxos de dados e blocos de anotações.

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 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 mais sofisticadas para controlar e gerenciar alterações em comparação com o SharePoint e o OneDrive. Manter um repositório bem organizado e documentado é essencial porque é a base de todo o conteúdo e colaboração.

Considere o uso do controle do código-fonte para controlar 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 de origem ou os princípios de DataOps.
  • Os criadores de conteúdo gerenciam conteúdo complexo ou importante ou esperam que o conteúdo seja dimensionado e cresça em complexidade e importância.

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

  • Git: Para confirmar e enviar 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 rastreia as alterações em seus arquivos. Para aprender 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 Visual Studio ou 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 a Stakeholder).
    • Pertencer a uma organização e a um projeto.
    • Permissões de repositório apropriadas.
  • Integração com o Fabric Git: para sincronizar conteúdo em um repositório remoto com um espaço de trabalho do Microsoft Fabric, os criadores de conteúdo usam a integração do Fabric Git. Isso é importante para controlar e gerenciar alterações no conteúdo criado no portal da malha, como fluxos de dados.

Gorjeta

Para facilitar o controle do código-fonte com o desenvolvimento local, recomendamos o uso de um aplicativo cliente como o Visual Studio Code. Você usa o Power BI Desktop para desenvolver conteúdo e, em seguida, pode usar o Visual Studio Code para executar o gerenciamento de controle de origem desse conteúdo, preparando, confirmando e enviando alterações por push para seu repositório remoto.

Aviso

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

Além disso, as etiquetas de sensibilidade não são suportadas com a integração do Fabric Git e a exportação de itens com etiquetas de sensibilidade pode ser desativada. Se o seu conteúdo tiver rótulos de sensibilidade, você deve planejar como obter o controle de versão e, ao mesmo tempo, honrar suas políticas de prevenção de perda de dados.

Um dos principais benefícios de usar o 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 e implantação de conteúdo.

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

Diagrama que mostra como colaborar usando o Azure DevOps.

Nota

O diagrama anterior descreve um exemplo de como colaborar usando o Azure DevOps. Escolha a abordagem que melhor se adapta às necessidades e à forma de trabalhar da sua equipa.

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

Item Descrição
Ponto 1. 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.
Ponto 2. O criador de conteúdo confirma suas alterações em um repositório local durante o desenvolvimento.
Ponto 3. 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.
Ponto 4. 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.
Ponto 5. 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.
Ponto 6. 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.
Ponto 7. Quando estiver pronto, o criador de conteúdo abre uma solicitação pull para mesclar a ramificação do recurso na ramificação principal.
Ponto 8. 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.
Ponto 9. 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.
Ponto 10. 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.
Ponto 11. 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.
Ponto 12. 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.
Ponto 13. 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.
Ponto 14. 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.

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 ramificações, confirmações, solicitações pull e mesclagens é essencial para se beneficiar mais do controle do código-fonte quando você gerencia o ciclo de vida do seu conteúdo do Power BI.

Usar ramificações

Os criadores de conteúdo conseguem a colaboração usando uma estratégia de ramificação. Uma estratégia de ramificação permite que criadores de conteúdo individuais trabalhem 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 feito 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 descritiva. Uma mensagem de confirmação descreve as alterações feitas nessa confirmação.

Ao usar uma estratégia de ramificação para gerenciar o conteúdo da malha, considere os seguintes fatores.

  • Qual ramo os criadores de conteúdo devem clonar para seu próprio trabalho. Por exemplo, se essas ramificações forem um clone da ramificação principal (conhecida como desenvolvimento baseado em tronco) ou se forem outras ramificações, como ramificações de liberação para versões específicas e planejadas de conteúdo.
  • Se você definirá o escopo de trabalhos específicos para versões de conteúdo distintas usando ramificações de versão.
  • Quais ramificações se conectam a qual espaço de trabalho quando você usa a integração do Fabric Git.

Gorjeta

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

Alterações em lote nas confirmações

Durante o desenvolvimento de conteúdo, os criadores devem organizar regularmente as 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 problema). Quando estiverem prontos, os criadores de conteúdo comprometem essas alterações por etapas.

As mudanças em lote desta forma têm vários benefícios.

  • Ajuda a estruturar o desenvolvimento e dá aos criadores de conteúdo a oportunidade de rever e documentar as alterações que agruparam.
  • Ele melhora o alinhamento entre planejamento e desenvolvimento, facilitando a vinculação de recursos e problemas e obtendo transparência sobre como o trabalho está prosseguindo.
  • Os proprietários técnicos podem analisar mais facilmente as solicitações pull dos criadores de conteúdo se as alterações forem agrupadas 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ê preparará e confirmará alterações de um repositório local ou do espaço de trabalho Malha.
  • Coloque arquivos .pbip em pastas de nível superior quando armazenar vários modelos ou relatórios em um único repositório. Isso facilitará a identificação e o agrupamento das alterações feitas.
  • 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 que você cometer sejam significativas.

Gorjeta

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

Criar solicitações pull para mesclar alterações

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.

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

  • Quais padrões e práticas você usará para realizar sua avaliação, se houver. Por exemplo, você pode usar regras do Best Practice Analyzer para modelos semânticos.
  • Como você revisará as alterações nos metadados do relatório, o que não é fácil de ler e entender sem usar ferramentas de terceiros.
  • Como você abordará e resolverá conflitos de mesclagem.

Gorjeta

Consulte Sobre solicitações pull e Estratégias de mesclagem e squash merge para obter orientações e recomendações específicas sobre como usar melhor as solicitações pull 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: certifique-se de que sua abordagem para desenvolver conteúdo esteja 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 encontrar arquivos .pbix mais fáceis de usar.
  • Modelo semântico separado e desenvolvimento de relatórios: o controle de versão é mais eficaz quando você gerencia alterações para diferentes tipos de itens, separadamente. Separar o desenvolvimento de modelos e relatórios é considerado uma boa prática.
  • Decida quantos espaços de trabalho você precisa: o uso de ambientes separados é fundamental para o sucesso do gerenciamento do ciclo de vida do conteúdo. Certifique-se de ter esclarecido quantos espaços de trabalho são necessários e realize um planejamento apropriado no nível do espaço de trabalho.
  • Decida como você implementará o controle de versão: decida entre uma abordagem mais simples usando o SharePoint ou o OneDrive for Business 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 OneDrive ou no Git Repo onde você armazenará conteúdo para acompanhar e gerenciar alterações.
  • Se você estiver usando o controle do código-fonte, configure os arquivos .gitignore e .gitattributes: certifique-se de configurar o repositório para acompanhar apenas as 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 sobre como você configurará e usará o controle do código-fonte para melhor dar suporte ao desenvolvimento. Evite complicar demais o seu processo. Em vez disso, tente complementar a maneira atual de trabalhar em suas equipes de desenvolvimento.

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