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 de planejamento de implementação do Power BI . A série se concentra no planejamento da implementação de uma experiência do Power BI dentro do Microsoft Fabric. Veja a introdução da série.

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:

• Centro de Excelência (COE) e equipes de BI: As equipes que são 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.

Observação

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

Sugestão

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 resolva 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.

Sugestão

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.

Sugestão

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. Para obter mais informações, consulte Decidir o formato do seu conteúdo mais adiante neste artigo.

Power BI Desktop (software de análise de dados)

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 quando usa 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. Para obter mais informações, consulte Decidir o formato do seu conteúdo mais adiante neste artigo.
• 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 estiveres a colaborar com outras pessoas, convém evitar a edição online em elementos partilhados, preferindo em vez disso trabalhares na tua 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.

Sugestão

Ao desenvolver fluxos de dados e painéis de resultados, recomendamos recuperar as definições de item para gerir alterações e armazenar uma cópia de segurança. Você pode automatizar o fluxo de dados e a recuperação de scorecard usando as APIs REST do Fabric. Especificamente, você pode usar os endpoints 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 os programadores criarem e gerirem 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 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 qual formato usará para salvá-lo e gerenciá-lo.

Decida o formato do seu conteúdo

Dependendo do conteúdo que você criará e das ferramentas que usará, seu conteúdo poderá usar formatos de arquivo diferentes. No entanto, mesmo dentro de uma ferramenta, você deve escolher entre diferentes formatos. Por exemplo, para relatórios e modelos semânticos criados com o Power BI Desktop, você precisa escolher entre arquivos .pbix e .pbip. Essa decisão tem um impacto funcional não apenas na forma como você desenvolve conteúdo, mas também como você gerencia esse conteúdo durante seu ciclo de vida e como você pode concluir determinadas tarefas de desenvolvimento com eficiência. Por exemplo, você deve usar arquivos .pbip se quiser desenvolver conteúdo no Power BI Desktop, mas publicar esse conteúdo usando a integração Git.

O formato de arquivo do seu conteúdo pode mudar durante seu ciclo de vida. Por exemplo, você pode começar a criar arquivos .pbix para relatórios e modelos, inicialmente. No entanto, quando novos criadores de conteúdo quiserem colaborar com você ou quando você quiser aumentar sua produtividade, você poderá mudar para um formato diferente, como arquivos .pbip.

As seções a seguir fornecem uma visão geral dos formatos comuns que você deve escolher no Power BI.

Formato de ficheiro do Power BI Desktop (.pbix)

O formato padrão e mais comum para relatórios e modelos do Power BI é o formato de arquivo .pbix. Este formato binário é fácil de gerenciar e usar para a maioria das pessoas. No entanto, não é possível abrir ou usar o conteúdo do arquivo para controlar alterações ou melhorar a produtividade do desenvolvedor.

Use o formato de arquivo .pbix quando:

• Você planeja publicar conteúdo usando a atualização do OneDrive.
• Os criadores de conteúdo querem usar e compartilhar um único arquivo em vez de uma pasta de vários arquivos (como no formato .pbip).
• Os criadores de conteúdo preferem o formato .pbix, porque o acham mais simples.

Formato de arquivo de Projetos do Power BI (.pbip)

Em vez de um arquivo .pbix, você também pode salvar conteúdo usando o formato Projetos do Power BI (.pbip ). Esse formato divide o arquivo em uma estrutura de pastas. Na estrutura de pastas de um .pbip, há vários arquivos de metadados que você pode abrir e ler que fornecem as definições e configurações para modelos e relatórios. Como você pode abrir e ler o conteúdo do arquivo, pode fazer alterações neles manualmente ou programaticamente, o que pode produzir melhorias significativas de produtividade. Alguns recursos do Fabric, como a integração com o Git, também exigem que você use o formato .pbip em vez do formato .pbix se desenvolver conteúdo no Power BI Desktop.

A imagem a seguir mostra como os arquivos .pbix e .pbip diferem:

Em resumo, os usuários ou processos automatizados podem exibir e modificar o conteúdo de um arquivo .pbip sem abri-lo no Power BI Desktop. Por outro lado, um arquivo .pbix é um arquivo binário e não há métodos suportados para exibir ou modificar seu conteúdo. Há vários cenários em que você deseja visualizar ou alterar esses conteúdos de metadados, como:

• Você deseja realizar o controle do código-fonte rastreando e gerenciando alterações, com visibilidade sobre o que mudou.
• Você deseja fazer alterações em massa ou procurar algo no arquivo.
• Você deseja reutilizar elementos do arquivo, como um visual, uma tabela ou uma medida.
• Você deseja exibir propriedades ou configurações que não estão visíveis na interface do usuário do Power BI Desktop.
• Você deseja automatizar determinados processos, como a verificação de metadados em busca de violações de práticas recomendadas antes de publicar conteúdo.

O formato de arquivo .pbip também pode usar os formatos TMDL ou PBIR para definições de modelo semântico e relatório, respectivamente, que têm suas próprias vantagens e considerações a ter em mente.

Use o formato de arquivo .pbip quando:

• Você planeja usar a integração do Git e não a atualização do OneDrive para publicar ou implantar conteúdo.
• Você planeja usar o controle do código-fonte para controlar e gerenciar alterações.
• Você planeja usar o Power BI Desktop em combinação com outras ferramentas para desenvolver modelos ou relatórios.
• Vários criadores de conteúdo colaborarão juntos em modelos ou relatórios.
• Você deseja se beneficiar de melhorias de produtividade e economizar tempo criando modelos ou relatórios.
• Você planeja automatizar partes do processo de desenvolvimento, teste ou implantação.
• Você deseja estruturar seus arquivos de modelo e relatório de maneiras diferentes (como vários relatórios no . Pasta de relatório e vários modelos no . Pasta SemanticModel).

Sugestão

Ao desenvolver conteúdo, você deve estar autoconsciente de cenários em que sente que está perdendo tempo, como com tarefas repetitivas. Nesses cenários, muitas vezes você pode economizar tempo aproveitando esses novos formatos junto com outras ferramentas, como Visual Studio Code, blocos de anotações no Fabric e muito mais.

Formato de ficheiro .tmdl (Tabular Model Definition Language)

Ao salvar um modelo como .pbip, você pode optar por salvá-lo como um único arquivo .bim que usa a TMSL (Tabular Model Scripting Language) ou em uma estrutura de pastas de vários arquivos .tmdl, que usam a nova Tabular Model Definition Language. A TMDL usa uma sintaxe semelhante a YAML para definições de modelo semântico que facilita a leitura e o gerenciamento de alterações de um modelo.

Segue-se um exemplo do aspeto do formato TMDL:

Algumas vantagens do novo formato TMDL são as seguintes:

• Você pode usar melhor o controle do código-fonte e a integração do Git, porque os metadados do modelo são mais concisos, estruturados e fáceis de ler.
• Você pode mesclar alterações mais facilmente sem criar conflitos.
• Você pode melhorar sua eficiência para determinadas tarefas de relatório, como reutilizar ou copiar objetos de modelo entre modelos (como uma tabela de datas).

Segue-se um exemplo do aspeto do controlo do código-fonte com o formato TMDL:

Use o formato TMDL quando:

• Você planeja usar o controle do código-fonte para controlar e gerenciar alterações.
• Você deseja melhorar a produtividade do desenvolvedor fazendo alterações de metadados.
• Você desenvolve seu modelo semântico usando outras ferramentas, como Visual Studio Code ou Editor de Tabela.

Observação

O formato TMDL é diferente do modo de exibição TMDL no Power BI Desktop:

• TMDL é um formato de linguagem e metadados para modelos semânticos.
• O modo de exibição TMDL é uma interface de script no Power BI Desktop para você fazer alterações programáticas no modelo. Ele usa uma sintaxe semelhante ao YAML para scripts TMDL como arquivos de formato TMDL. Você não precisa usar o formato TMDL para se beneficiar da visualização TMDL.

Formato de relatório avançado (PBIR) do Power BI.

Ao salvar o conteúdo como um arquivo .pbip, você pode optar por usar o formato de relatório padrão ou o novo formato PBIR. Este novo formato apresenta várias vantagens que podem melhorar a produtividade e colaboração do desenvolvedor, particularmente quando você usa o formato PBIR com arquivos .pbip.

A seguir, encontra-se um exemplo de como é o formato PBIR:

Algumas vantagens de usar o formato PBIR são as seguintes:

• Você pode usar melhor o controle do código-fonte e a integração com o Git, porque os metadados do relatório são mais concisos, estruturados e fáceis de ler.
• Você pode melhorar sua eficiência para determinadas tarefas de relatórios, como:
  • Reutilizar ou copiar elementos visuais entre páginas copiando o visual.json.
  • Reutilizar ou copiar páginas entre relatórios.
  • Encontrar e substituir cores, campos e outras configurações visuais personalizadas de uma só vez.
  • Corrigir visuais "quebrados" com campos que foram renomeados ou movidos entre tabelas.
• Você pode adicionar anotações de metadados para relatar metadados para facilitar determinadas automações ou tarefas que oferecem suporte à integração contínua/implantação contínua (CI/CD).
• Você pode aproveitar ferramentas como laboratórios de link semântico que têm mais utilidade com o novo formato PBIR.

Use o formato PBIR quando:

• Você planeja usar o controle do código-fonte para controlar e gerenciar alterações.
• Você deseja melhorar a produtividade do criador de relatórios fazendo alterações nos metadados.
• Você deseja fazer alterações programáticas ou automáticas no relatório.

Atenção

Certifique-se de verificar primeiro as limitações e considerações antes de usar o formato PBIR. Essas limitações e considerações mudam com o tempo, portanto, verifique regularmente se há certos itens que impedem você de cumprir um requisito específico para seu conteúdo do Power BI.

Além disso, todos os metadados do relatório, independentemente do seu formato, têm o potencial de incluir pontos de dados. Para obter mais informações, consulte Pasta e Ficheiros PBIR.

Formato de ficheiro de modelo do Power BI (.pbit)

Você também pode salvar um relatório ou modelo semântico do Power BI como um arquivo .pbit. No entanto, os arquivos .pbit destinam-se à reutilização de um layout de relatório específico ou estrutura de modelo. Você não deve usar o formato .pbit para salvar e gerenciar o conteúdo do Power BI durante seu desenvolvimento. Em vez disso, você deve usar arquivos .pbit quando quiser criar modelos reutilizáveis para compartilhar com outras pessoas em sua organização.

Outros formatos

Ao desenvolver outro conteúdo no Power BI (como dashboards, fluxos de dados ou relatórios paginados), talvez não tenha ficheiros de conteúdo caso desenvolva o item no Fabric. Como alternativa, você só pode salvar a definição do item no controle do código-fonte. Para obter mais informações, consulte Decidir onde armazenar arquivos no artigo anterior desta série.

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 Fabric. 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 utilize espaços de trabalho do Fabric separados, conforme descrito nos artigos de planeamento 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?
• Irão os espaços de trabalho pertencer a um ciclo de implementação do Fabric, ou irá orquestrar a implementação usando outras abordagens, como 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 auxiliares separados para itens em ambientes 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.

Observação

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.
• Implantação de conteúdo de outro espaço de trabalho usando pipelines de implantação do Fabric.
• Sincronização de conteúdo de um repositório Git remoto usando a integração Git.
• Desenvolvendo conteúdo programaticamente usando as Fabric REST APIs, Power BI REST APIs, ou os 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 descreve os seguintes processos e componentes para separar espaços de trabalho nesta abordagem.

Número	Descrição
	Os criadores de conteúdo desenvolvem conteúdo em seu ambiente local.
	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.
	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.

Observação

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.

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

Número	Descrição
	Os criadores de conteúdo desenvolvem conteúdo em seu ambiente local.
	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.
	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.
	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.

Observação

Você pode usar até dez ambientes diferentes nos 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.

Observação

Azure DevOps é um conjunto de serviços que se integram com o Power BI e o Fabric para ajudar no planeamento e na orquestração da gestão do ciclo de vida de conteúdos. 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.
• Wiki do Azure: 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.

Observação

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.

Número	Descrição
	Cada criador de conteúdo desenvolve conteúdo em seu próprio ambiente local.
	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.
	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.
	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 de forma independente, em ramos separados, enquanto fazem alterações.
	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.
	Quando prontos, os criadores de conteúdo executam uma solicitação pull para mesclar suas alterações na ramificação principal da solução.
	Depois de mesclar as alterações, a ramificação principal é sincronizada com o espaço de trabalho de desenvolvimento.
	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.
	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.
	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 separados de gateways de dados locais e gateways VNet para cargas de trabalho em produção. Isso é benéfico para evitar interrupções, mas também para garantir a disponibilidade quando 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 vez do Azure DevOps, você também pode usar o GitHub. 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.

Sugestão

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.

O diagrama descreve os seguintes processos e componentes.

Número	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.
	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.
	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.
	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.
	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.

Observação

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 as usarem para a 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. Após concluir as alterações, registe os ficheiros com comentários que descrevam a mudança. O registo e a remoção de ficheiros ajudam os utilizadores a melhorar a colaboração entre criadores de conteúdo quando utilizam o SharePoint ou o OneDrive para o Trabalho e para a Escola para controlo 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 para um repositório Git remoto, como o Azure Repos ou o GitHub.

Observação

Você também pode executar o controle do código-fonte do seu conteúdo sem usar a integração com o Git. Neste cenário, continua a controlar e a gerir as alterações de conteúdo num repositório Git remoto, mas implanta o conteúdo utilizando as APIs REST ou os endpoints de leitura/escrita 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 desenvolvendo conteúdo localmente e, em seguida, confirmando alterações em um repositório remoto, que pode sincronizar com um espaço de trabalho do Fabric usando a integração do Git.

O diagrama descreve os seguintes processos e componentes.

Número	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 modelos.
	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.
	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.
	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.
	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.
	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.

Sugestão

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.

Advertência

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 ou o GitHub é a colaboração aprimorada entre os criadores de conteúdo e mais personalização e supervisão em relação às alterações e à implantação do 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. Você também pode usar o GitHub Enterprise em vez do AzureDevOps, que envolveria diferentes serviços que executam uma função semelhante.

Observação

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.

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

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 na sua solução local é confirmado e enviado por push para uma versão do branch 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 gerir o conteúdo do Fabric, 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.
• Que ramificações se ligam a que espaço de trabalho ao usar a integração do Fabric Git.

Sugestão

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 'commitem' estas alterações preparadas.

Deste modo, as mudanças em lote 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.

• Quer você proceda a preparar e confirmar alterações de um repositório local ou do espaço de trabalho Fabric.
• 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.

Sugestão

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.

Sugestão

Consulte Sobre pull requests e Estratégias de mesclagem e squash merge para obter orientações e recomendações específicas sobre como usar melhor os 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: 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.

Conteúdo relacionado

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