Tutorial: Como implantar alterações no AI/BI Dashboard com segurança e em escala com Declarative Automation Bundles

A ideia de começar uma reunião de diretoria com um dashboard cheio de erros deveria tirar o sono das equipes de análise. O mesmo vale para descobrir, depois do ocorrido, que um plano de contratação, lançamento de produto ou previsão de receita foi baseado em uma métrica incorreta. Ou que uma equipe de suporte emitiu reembolsos demais porque um dashboard apresentou incorretamente o histórico de compras de um cliente.

Essas falhas raramente são causadas por uma análise ruim. Como qualquer sistema de produção, elas geralmente surgem de dashboards atualizados manualmente à medida que os modelos de dados e requisitos evoluem — sem controle de versão, sem um processo de revisão confiável ou sem uma maneira repetível de promover alterações entre ambientes.

Este post de blog defende uma ideia simples: dashboards de nível de produção que impulsionam os negócios devem ser gerenciados com a mesma disciplina que o código de produção. Como o Databricks AI/BI roda na mesma Data Intelligence Platform que seus pipelines de dados e camada de governança, as equipes também podem aplicar essas mesmas práticas de produção — controle de versão, configuração específica do ambiente e implantação controlada — aos dashboards.

Para tornar isso concreto, apresentaremos como os analistas podem usar os recursos de nível de produção do Databricks sem alterar a forma como criam dashboards no dia a dia.

Especificamente, mostraremos como esse fluxo permite que você:

• Revise e aprove cada alteração em um dashboard
• Acompanhe o histórico de um dashboard e associe alterações de código aos requisitos de negócios
• Reverta um dashboard para uma versão anterior

Pré-requisitos

Este fluxo de trabalho exige uma configuração inicial de infraestrutura que a maioria das organizações já possui. Se você ainda não tiver isso, peça ajuda ao seu grupo interno de DevOps ou TI para configurar:

• Pelo menos dois workspaces do Databricks (por exemplo, um workspace de desenvolvimento e outro de produção) para criar, testar e implantar dashboards
• Pastas baseadas em Git no Databricks (AWS | Azure | GCP), usadas para versionar definições de dashboard
• Declarative Automation Bundles (DABs) (AWS | Azure | GCP) configurados para o projeto

Introdução: Um fluxo de trabalho estruturado para publicar alterações de dashboard com segurança

Vamos passar por um cenário realista: você é responsável por um dashboard de Desempenho de Vendas usado semanalmente pela liderança de Finanças e Vendas. Ele começou como um projeto de estagiário criado diretamente em um workspace, mas evoluiu com o tempo e agora é usado em várias revisões executivas.

Uma mudança de prioridades decorrente de uma reunião de diretoria traz um novo requisito: a equipe de Finanças agora precisa acompanhar os valores de vendas confirmados e não confirmados, substituindo uma única métrica de vendas agregada, e o dashboard precisa refletir a nova definição antes da próxima revisão de previsão.

Esses valores alimentam diretamente decisões de negócios reais, incluindo cálculos de remuneração e bônus, então vamos colocar este dashboard em um caminho de implantação disciplinado pela primeira vez.

Etapa 1: Adicionar o dashboard a um Declarative Automation Bundles

Antes de iniciar o processo, trabalhe com seu grupo de TI para configurar algumas ferramentas básicas de código: um repositório Git com um "Declarative Automation Bundles" vazio e alguns scripts de CI/CD para implantar o pacote automaticamente.

Um repositório Git é uma ferramenta para acompanhar as alterações de arquivos — para começar, precisamos conectá-lo ao Databricks para podermos rastrear as alterações na configuração do dashboard. No workspace do Databricks, crie uma pasta Git e cole a URL do repositório na caixa de diálogo de configuração. Isso faz com que o Databricks reconheça o repositório e nos permite adicionar o dashboard a ele na próxima etapa.

Um Declarative Automation Bundles é uma forma de agrupar arquivos de código (neste caso, um dashboard). Se o repositório já contiver um pacote, ele será detectado automaticamente e poderá ser aberto usando o ícone de seta. Caso contrário, um novo pacote poderá ser criado a partir do menu Criar na pasta Git.

Dentro do editor do Asset Bundle, você pode adicionar componentes novos e existentes ao pacote que está atualmente vazio. Para incluir o dashboard, abra o menu Adicionar e selecione Adicionar dashboard existente. Depois de adicioná-lo, você verá o dashboard aparecer dentro da pasta src como parte do pacote.

A partir deste ponto, o dashboard é gerenciado como um ativo implantável, facilitando a promoção do mesmo dashboard entre workspaces de desenvolvimento, teste e produção.

Por fim, faça o commit do dashboard no repositório. Isso captura o estado atual do dashboard como uma linha de base e estabelece um ponto de partida claro para rastrear e revisar alterações futuras.

Você verá que o dashboard foi adicionado ao repositório, junto com alguns arquivos de configuração gerados automaticamente (terminando com .yml). Esses arquivos descrevem como o dashboard deve ser implantado em diferentes ambientes — você não precisa editá-los.

Adicione uma nota curta descrevendo o que você fez no campo de mensagem de commit e selecione Commit & Push. Isso cria um ponto de verificação para o dashboard — um estado sabidamente funcional ao qual você pode retornar mais tarde — para que as alterações futuras possam ser comparadas, revisadas e implantadas com segurança.

Etapa 2: Atualizar o dashboard

Agora que o dashboard existente foi enviado (commit), você pode começar a fazer alterações nele sem afetar o que já está em produção, e o Git rastreará as alterações específicas que você fez.

A prática recomendada é criar uma branch do Git — uma versão do dashboard para trabalhar sem afetar os outros. Você pode fazer isso por meio do botão Create Branch e, em seguida, dar a ela um nome descritivo, como seu nome, a funcionalidade ou o número do ticket associado à alteração. Pense nisso como uma versão privada para sua atualização: você pode editar, testar e refinar o dashboard livremente e, depois, decidir separadamente quando suas alterações estarão prontas para serem revisadas e implantadas.

Agora você pode fazer as alterações no dashboard! Neste caso, você modificará o número de vendas no canto superior esquerdo para adicionar contadores de vendas confirmadas e não confirmadas (azul e vermelho em negrito foram escolhidos para maior visibilidade).

Você notará que nada muda na experiência de criação — faça essas alterações como faria normalmente usando o editor de UI do dashboard.

Assim que o dashboard estiver correto em desenvolvimento, você estará pronto para prosseguir e levar as alterações para a produção. Use o mesmo botão do Git na parte superior, como antes, para registrar essas alterações com uma mensagem curta de commit.

Etapa 3: Revisar a alteração

Em seguida, você desbloqueia outro benefício fundamental desse fluxo de trabalho: um espaço para que outras pessoas revisem as alterações e enviem feedback antes que elas cheguem à produção. A necessidade de revisão por uma segunda pessoa é uma prática recomendada geral, mas, igualmente importante, cria um espaço seguro para discutir ideias, validar suposições e refinar a alteração antes que ela afete os relatórios.

Para iniciar a revisão, crie um Pull Request (PR) no seu provedor Git, que é basicamente uma página de revisão para a atualização do dashboard. O revisor pode ver exatamente o que mudou, deixar comentários para você responder e aprovar a atualização assim que tudo estiver correto.

Durante a revisão, o dashboard de produção permanece inalterado. Apenas depois que o feedback for resolvido e a alteração for aprovada é que ela segue em frente.

Embora as alterações no dashboard sejam armazenadas e monitoradas como arquivos de configuração nos bastidores, geralmente é difícil entender o que realmente mudou. Por isso, a maioria das equipes usa uma pequena automação para implantar automaticamente uma versão de teste temporária do dashboard para revisão sempre que um PR é aberto. Dessa forma, os revisores podem ver as métricas, cálculos e layouts propostos no contexto antes que qualquer coisa chegue à produção, além de identificar problemas de lógica de dados ou de UI. Fazer com que o desenvolvedor ou revisor inclua capturas de tela ou links para o dashboard de teste diretamente no PR também torna o feedback mais rápido e seguro.

Os revisores podem adicionar comentários e aprovar, o que fica registrado para que a alteração seja mais fácil de entender mais tarde.

Etapa 4: Fazer o deploy do dashboard em produção usando o bundle

Com a alteração aprovada, você está pronto para fazer o deploy do dashboard em produção.

Geralmente, os dashboards precisam de configurações diferentes em produção e em desenvolvimento — por exemplo, apontar para um catálogo ou esquema de produção em vez de um conjunto de dados de desenvolvimento, ou usar um SQL warehouse diferente.

A boa notícia é que essas diferenças são esperadas e tratadas como parte do processo de deploy.

Quando você adicionou o dashboard ao Asset Bundle, o Databricks gerou um pequeno arquivo de configuração .yml que captura essas configurações específicas do ambiente. Esse arquivo permite substituir valores por ambiente sem alterar a lógica do próprio dashboard. No nosso caso, especificamos que o catálogo que o dashboard usa em produção deve ser diferente do de teste, usando um valor ${variable} para o nome do catálogo.

Por fim, o arquivo databricks.yml vincula todos os recursos do bundle e define qual catálogo é usado em cada ambiente, facilitando o gerenciamento de deploys consistentes em workspaces de desenvolvimento, teste e produção.

Assim que o Pull Request for aprovado e mesclado na branch principal, sua automação de deploy será executada e usará os valores específicos do ambiente definidos em databricks.yml. O mesmo código de dashboard é reutilizado em todos os workspaces, enquanto configurações como catálogo, esquema e warehouse são aplicadas com base no ambiente de destino. Isso elimina a necessidade de manter cópias separadas do dashboard para cada workspace e garante que as alterações se comportem de maneira previsível em todos os lugares.

Na maioria dos provedores Git, você poderá ver a automação de deploy no pull request para monitorar a implantação e confirmar quando ela for concluída (ou se encontrar algum problema). Se ocorrer um problema, o deploy será interrompido sem afetar o dashboard de produção existente para permitir que você resolva o problema. Assim que o deploy for concluído com sucesso, o dashboard atualizado estará ativo em produção e pronto para os stakeholders!

Bônus 1: E se você quiser inspecionar o histórico?

Assim que a atualização do dashboard estiver ativa, talvez você precise entender o histórico do que mudou, quando e por quê. Um bônus desse fluxo é que a alteração agora é rastreável. Em vez de uma edição pontual feita diretamente em um workspace, ela aparece como uma sequência de versões salvas.

Cada entrada representa uma atualização do dashboard, junto com o autor e o timestamp. Você pode abrir qualquer entrada para revisar as alterações e revertê-las, se necessário.

Bônus 2: E se você precisar reverter uma alteração?

Mesmo com uma revisão e testes cuidadosos, problemas ainda podem surgir — como um dashboard que não carrega ou uma definição de métrica que se mostra incorreta.

Como o dashboard é gerenciado por meio desse fluxo de trabalho, você pode reverter para uma versão sabidamente estável usando o mesmo processo controlado usado para fazer o deploy da atualização.

Comece abrindo o histórico de alterações do dashboard no repositório e localizando a atualização que deseja desfazer. A partir daí, você pode revisar o que foi modificado para confirmar que está revertendo a alteração correta antes de prosseguir.

A partir dos detalhes da alteração, siga o link de volta para a página de revisão. Para reverter a atualização, selecione Revert. Isso cria uma nova alteração de "desfazer" que reverte apenas essa atualização específica, restaurando o dashboard para sua lógica anterior e mantendo o restante do histórico do dashboard intacto.

Assim que a alteração for mesclada ao branch principal, a mesma automação que implantou o dashboard em produção fará a reversão. Isso significa que você pode responder a uma interrupção ou a um problema de cálculo de alto impacto em minutos, sem ignorar os controles que já possui.

Bônus 3: E se suas fontes de dados tiverem uma atualização?

A maioria dos dashboards está intimamente ligada às suas fontes de dados, o que significa que as atualizações em um dashboard geralmente estão associadas a atualizações nos pipelines. A boa notícia é que os Asset Bundles foram projetados para agrupar componentes relacionados em um único pacote.

Isso garante que uma alteração no modelo de dados upstream nunca pegue você de surpresa e, quando as alterações de visualização exigirem atualizações no modelo de dados, você poderá implementar ambas as alterações em uma única implantação.

Conclusão

Tratar dashboards de AI/BI como produtos de dados de nível de produção é essencial para decisões de negócios confiáveis e mitigação de riscos. Neste fluxo de trabalho, um pequeno conjunto de etapas adicionais torna as alterações no dashboard visíveis, revisáveis e reversíveis — sem mudar a forma como você cria dashboards no dia a dia.

Ao gerenciar dashboards com Git e Bundles de Automação Declarativa, as equipes estabelecem um fluxo de trabalho rotineiro e previsível para atualizações: faça a alteração, revise-a, teste-a e implante-a. O mesmo processo se aplica se a atualização for um pequeno ajuste visual ou uma alteração significativa na lógica de negócios.

Com a disciplina de implantação correta, as alterações nos dashboards deixam de ser uma fonte de risco e se tornam uma fonte confiável de insights que evolui com a empresa, mesmo em situações de alta responsabilidade, como uma reunião de diretoria.

Saiba mais + Próximos passos

Se você se inspirou e quer se aprofundar nos elementos usados neste fluxo de trabalho, aqui estão alguns recursos ideais para continuar:

• ‘Estratégia de ramificação’ (AWS | Azure | GCP)
  Saiba como as alterações são mescladas e implantadas usando um modelo de ramificação que segue as melhores práticas.
• Bundles de Automação Declarativa (AWS | Azure | GCP)
  Saiba como os Asset Bundles são usados para empacotar e implantar recursos do Databricks de forma consistente em todos os ambientes.
• CI/CD para implantação automatizada no Databricks (AWS | Azure | GCP)
  Saiba como implementar CI/CD com scripts iniciais do GitHub Actions (AWS | Azure | GCP)
• Uso de Asset Bundles a partir da UI do espaço de trabalho do Databricks (AWS | Azure | GCP)
  Saiba como criar, editar e implantar bundles diretamente do espaço de trabalho.
• Pastas baseadas em Git no Databricks (AWS | Azure | GCP)
  Saiba como funciona a integração com o Git no Databricks e como o controle de versão se integra aos fluxos de trabalho diários de análise.

Se você estiver pronto para dar o próximo passo com o Databricks AI/BI, poderá escolher qualquer uma das seguintes opções:

• Edição gratuita e avaliação: Obtenha experiência prática inscrevendo-se em nossa edição gratuita ou avaliação.
• Documentação: Aprofunde-se nos detalhes com nossa documentação.
• Página web: Visite nossa página web para saber mais.
• Demonstrações: Assista aos nossos vídeos de demonstração, faça tours pelo produto e obtenha tutoriais práticos para ver o AI/BI em ação.
• Treinamento: Comece com o treinamento gratuito do produto por meio da Databricks Academy.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original