Confira como aplicar o versionamento de relatórios no Power BI com PBIP e Git, ganhando mais controle, organização e eficiência no desenvolvimento.

O objetivo deste artigo é demonstrar o versionamento de relatórios Power BI utilizando repositórios com a extensão PBIP. Além disso, será apresentado um passo a passo para a configuração inicial, um exemplo de uso real com commits, branching e merges, bem como uma listagem de melhores práticas e tecnologias complementares oferecidas pelo Power BI Service para aprimorar ainda mais o processo geral de versionamento de relatórios.

Passo a passo para configuração inicial

O PBIP é uma extensão de arquivos do Power BI que salva as definições do modelo semântico e do relatório como arquivos de texto, em uma estrutura de pastas simples e intuitiva. Essa extensão permite a edição do relatório a partir dos arquivos de texto, possibilitando operações em lote (como adicionar um conjunto de medidas a tabelas de uma vez), controle de código-fonte e integração com sistemas CI/CD.

A extensão ainda é uma preview feature. Para ativá-la, vá em: Arquivo > Opções > Global > Recursos em versão prévia.

Após salvar o arquivo como .pbip, repare que foi criado um diretório contendo os itens do relatório e do modelo semântico, salvos como arquivos de texto:

O próximo passo é inicializar um repositório GIT. Os repositórios podem ser acessados e gerenciados por meio de ferramentas de linha de comando, como o Visual Studio Code, ou por meio de interfaces gráficas mais simples (as GIT GUI). Por serem mais amigáveis para novos usuários, neste artigo será utilizado o GitHub Desktop, interface gráfica desenvolvida pelo GitHub (GitHub Desktop | Simple collaboration from your desktop).

Caso deseje utilizar o Visual Studio Code, a Microsoft disponibiliza um artigo ensinando a configuração inicial: Integração do Git com projetos do Power BI Desktop - Power BI | Microsoft Learn.

A configuração inicial utilizando o GitHub Desktop é bem simples: basta ir em File > New repository e adicionar o local da pasta criada pelo PBIP, definindo o nome do repositório e a descrição:

Após a criação do repositório, será possível publicá-lo no GitHub, clicando em Publish repository:

Será necessário integrar a conta do GitHub com o GitHub Desktop e definir um nome e uma descrição para o repositório na nuvem. O primeiro commit irá enviar os arquivos do repositório local para o repositório no GitHub.

Exemplo prático de utilização

A fim de demonstrar a utilização dessa extensão para controlar o versionamento via Git, foi elaborado o seguinte cenário hipotético de aplicação:

Neste cenário, são exemplificadas duas formas de gerenciar versionamento em Git. A primeira é o workflow centralizado, no qual as alterações são realizadas diretamente na main (C1 e C2). A segunda é o feature branching, prática que consiste em criar branches (ramificações) no sistema de controle de versão Git para o desenvolvimento de novas funcionalidades (C3 a C5).

Existem diversas outras formas de operar um projeto versionado em Git; a estratégia escolhida dependerá do time envolvido e da aplicação.

O fluxo de trabalho ocorre da seguinte forma:

• C0 – Commit inicial que faz o upload do repositório para o GitHub.

• C1 – Criação de uma medida; mudança realizada na main.

• C2 – Criação de outra medida; mudança realizada na main.

• C3 – Criação de uma branch específica para resolução de um chamado criado no Jira (#00001). Para conclusão do chamado, era necessário criar uma nova medida e corrigir um erro no tratamento dos dados. Neste commit, a nova medida foi criada.

• C4 – Durante uma avaliação no dashboard, foi notado que um visual estava sem título. Requisitaram um hotfix, com prioridade mais alta que o chamado do Jira, que já estava em desenvolvimento. Para isso, foi criada outra branch, chamada Hotfix. Nessa branch foi realizado um commit (C4) aplicando a correção no visual. Após a correção, foi realizado o merge dessa branch com a main, e o dashboard pôde ser publicado no serviço do Power BI. Como a implementação do hotfix estava em uma branch separada, o commit anterior referente à criação da nova medida não foi levado para a main. Essa é uma das funcionalidades mais interessantes do uso de repositórios, pois permite que mais de um desenvolvedor trabalhe em um mesmo relatório, facilita testes e possibilita a escolha de quais itens desenvolvidos vão para produção.

• C5 – Após a correção emergencial do commit anterior, a pessoa desenvolvedora pôde retomar o trabalho do chamado do Jira. Foi realizado um novo commit aplicando a correção no tratamento dos dados. Após isso, foi feito o merge dessa branch na main, levando ao dashboard as features desenvolvidas em C3 e C5.

No GitHub Desktop, podemos visualizar o histórico de commits:

Todas essas implementações foram feitas editando o arquivo PBIP no Power BI Desktop e, em cada um dos commits, podemos visualizar as alterações realizadas nos arquivos de texto do repositório. Essas mudanças também podem ser observadas no site do GitHub. Em C5, por exemplo, é possível ver a alteração da tipagem das colunas “Valor” e “Quantidade” de string para int64:

Boas práticas de versionamento com Git

Para garantir a eficiência e a qualidade no versionamento de dashboards utilizando Git, é fundamental seguir práticas consolidadas de controle de versão. A seguir, estão as principais recomendações, de acordo com o GitLab:

• Manter commits atômicos: cada commit deve representar uma única unidade de trabalho, contendo apenas uma tarefa ou correção específica. Commits atômicos tornam o processo de revisão mais ágil, facilitam reverts em caso de problemas e preservam a integridade do histórico de alterações.

• Desenvolver utilizando branches: utilizar branches para isolar novos desenvolvimentos da main, promovendo organização e reduzindo riscos de introdução de falhas.

• Escrever mensagens de commit descritivas: as mensagens devem ser claras, explicando de forma autossuficiente o que foi alterado.

• Definir uma estratégia de branching: adotar um modelo de branching padrão para todos os projetos assegura consistência e eficiência no fluxo de trabalho.

Em relação a outras funcionalidades do serviço do Power BI que apoiam a organização do fluxo de trabalho, é possível integrar o versionamento diretamente aos workspaces. Com essa integração, qualquer alteração feita nos relatórios online pode ser enviada como um commit diretamente do serviço do Power BI para repositórios no GitHub ou Azure DevOps (saiba mais em: Get started with Git integration - Microsoft Fabric | Microsoft Learn).

Outra funcionalidade são os Deployment Pipelines, um recurso que permite a criação de ambientes de desenvolvimento, homologação e produção nos workspaces do Power BI (mais informações em: Get started using deployment pipelines, the Fabric Application lifecycle management (ALM) tool - Microsoft Fabric | Microsoft Learn).

Vale destacar que, para habilitar tanto a integração com Git diretamente nos workspaces quanto o uso de Deployment Pipelines, é necessário que a organização possua uma capacidade Fabric ativa.

Agora que você conhece o processo, é só aplicar e aproveitar os benefícios do versionamento no Power BI.