Uso e fluxo de trabalho de CI/CD do Looker de várias camadas

Nesta página, explicamos como usar um fluxo de trabalho de CI/CD de várias camadas no Looker depois que ele for instalado e configurado.

Estas instruções usam um sistema de três níveis que inclui desenvolvimento, controle de qualidade e produção. No entanto, é possível aplicar os mesmos princípios a um sistema de duas ou quatro camadas.

Estas instruções também pressupõem o uso do GitHub como seu provedor Git. Você pode usar outros provedores do Git para criar um fluxo de trabalho de CI/CD. No entanto, é necessário ter experiência para modificar essas instruções para seu provedor.

Visão geral do fluxo de trabalho

Os desenvolvedores do LookML começam escrevendo código na ramificação de desenvolvimento, que normalmente tem um nome como dev-my-user-ydnv, testam as mudanças com a integração contínua do Looker (ou executando manualmente um conjunto de CI) e fazem commit do código. Por fim, eles abrem uma solicitação de envio para mesclar o código com a ramificação main.

Quando a solicitação de envio é aberta, ela leva o desenvolvedor ao GitHub. O desenvolvedor precisa escrever um título de solicitação de pull significativo usando o estilo de commits convencionais e adicionar um comentário à descrição que será incluída no changelog. Se o acionamento de solicitação de pull estiver configurado, a Integração Contínua do Looker vai validar automaticamente a solicitação de envio, e os desenvolvedores poderão ver os resultados no Looker ou no GitHub.

Em seguida, o desenvolvedor precisa selecionar um revisor no GitHub. O revisor vai receber uma notificação e poderá adicionar a avaliação ao PR. Se o revisor aprovar a mudança, a solicitação de envio será mesclada com a ramificação main. Um WebHook é chamado, e o ambiente de desenvolvimento agora vê a mudança.

Automaticamente, a automação Release Please será executada e abrirá uma segunda solicitação de pull para criar uma nova versão com tag. Se já houver um PR aberto para essa finalidade, o Release Please vai atualizar esse PR. O PR de lançamento tem um número de versão associado a ele, bem como um changelog que inclui os títulos e as descrições das mudanças incluídas.

Quando o PR gerado pelo Release Please é aprovado e mesclado, uma nova tag de versão é gerada, e o changelog é mesclado com a ramificação main. As instâncias de controle de qualidade e produção do Looker podem selecionar essa versão usando o Modo de implantação avançado.

Práticas recomendadas para numerar versões e nomear commits

As versões e as tags associadas podem ser nomeadas e numeradas de qualquer maneira que faça sentido no seu ambiente. No entanto, o controle de versões semântico é usado aqui e é altamente recomendado porque funciona bem com o plug-in Release Please.

No controle de versão semântico, a versão consiste em três números separados por pontos: MAJOR.MINOR.PATCH

  • PATCH é incrementado sempre que uma versão corrige um bug.
  • MINOR é incrementado e PATCH é redefinido como zero sempre que a versão adiciona ou refina um recurso, mantendo a compatibilidade com versões anteriores.
  • MAJOR é incrementado, e MINOR e PATCH são definidos como zero quando um recurso não compatível com versões anteriores é adicionado.

O Conventional Commits (em inglês) é um sistema de nomenclatura de commits pelo impacto que eles têm nos usuários finais. Embora não seja obrigatório, o uso de nomes de commit convencionais também é útil para o plug-in Release Please.

Na nomenclatura convencional de commits, cada mensagem de commit é precedida por um indicador do escopo da mudança:

  • Uma correção de bug é indicada com fix:, como fix: set proper currency symbol on sale_amt format.
  • Um novo recurso é indicado com feat:, como feat: added explore for sales by territory.
  • Um recurso com uma mudança incompatível é indicado por feat!:, como feat!: rewrote sales explore to use the new calendar view.
  • Quando a documentação é atualizada, mas o LookML não é alterado, a mensagem de commit começa com doc:

Se os commits convencionais forem usados de forma consistente, geralmente é fácil determinar o número semântico a ser usado em seguida. Se o registro de confirmação consistir apenas em confirmações fix: e doc:, o PATCH vai ser incrementado. Se houver um commit de feat:, MINOR precisará ser incrementado. Se houver um feat!:, MAJOR deverá ser incrementado. O plug-in Release Please pode até gerar um arquivo CHANGELOG e marcar a versão automaticamente.

Como usar o modo de implantação avançado

Depois que as mudanças forem feitas e enviadas como um PR na instância de desenvolvimento, o plug-in Release Please vai marcar as mudanças com uma tag de versão, como v1.2.3. O Modo de implantação avançado do Looker disponibiliza essas versões na interface do Looker para as instâncias de controle de qualidade e produção.

Para implantar uma mudança, escolha o Deployment Manager no IDE do Looker:

Localização do Deployment Manager do Looker no IDE.

Clique no link Selecionar commit no canto superior direito do Deployment Manager. Em seguida, selecione o menu de três pontos associado à tag que você quer implantar e escolha Implantar no ambiente:

Interface do Deployment Manager do Looker para implantação no ambiente.

Não é necessário adicionar tags à implantação novamente. Escolha Implantar sem adicionar tags e pressione o botão Implantar no ambiente:

Interface do Deployment Manager do Looker para implantação sem inclusão de tags.

Por fim, envie para produção usando o Deployment Manager.

Como usar a integração contínua do Looker

Para verificar mudanças em uma ramificação de desenvolvimento ou como parte de uma solicitação de envio, os desenvolvedores podem usar a integração contínua do Looker. A integração contínua oferece os seguintes validadores:

É possível agrupar esses validadores em suites de integração contínua e executá-los automaticamente em solicitações de pull, de acordo com uma programação ou manualmente.

Validador de SQL

O validador de SQL de integração contínua verifica se as dimensões nas suas análises detalhadas são executadas corretamente no banco de dados. Ele testa se os campos definidos nas visualizações do LookML correspondem a colunas ou expressões SQL válidas no banco de dados.

O validador de SQL tem os seguintes recursos principais:

  • Executa consultas com cláusulas LIMIT 0 e WHERE 1=2 para validar o SQL sem gerar custos de verificação de dados.
  • Oferece suporte à validação incremental para testar apenas as análises que mudaram na ramificação de desenvolvimento.
  • Validações de escopo para consultar ou excluir análises detalhadas específicas.
  • Exclui dimensões específicas da validação usando tags do LookML ou comentários em SQL (tags: ["ci: ignore"] ou -- ci: ignore).

Para mais informações e opções de configuração, consulte a página de documentação do Validador de SQL de integração contínua.

Validador do LookML

O validador LookML de integração contínua verifica se há erros de sintaxe no seu projeto do LookML, como colchetes ausentes ou referências de campo inválidas. Esse validador é especialmente útil para desenvolvedores que escrevem LookML fora do IDE do Looker.

O validador do LookML tem os seguintes recursos principais:

  • Permite definir um limite de gravidade (erro, aviso ou informação) que determina qual nível de gravidade da mensagem causa falha em uma execução.
  • Permite configurar uma duração de tempo limite para execuções de validação.

Para mais informações e opções de configuração, consulte a página de documentação Validador de LookML de integração contínua.

Validador de conteúdo

O Validador de conteúdo de integração contínua verifica se o conteúdo salvo, como Looks e dashboards definidos pelo usuário (UDDs), ainda funciona corretamente após as mudanças no LookML.

O Validador de Conteúdo tem os seguintes recursos principais:

Para mais informações e opções de configuração, consulte a página de documentação do Validador de Conteúdo de Integração Contínua.

Validador Assert

O validador de asserções de integração contínua executa testes de dados do LookML definidos no projeto para verificar a lógica do modelo e a integridade de dados.

Por exemplo, um teste de dados do LookML pode ser assim:

test: historic_revenue_is_accurate {
  explore_source: orders {
    column: total_revenue { field: orders.total_revenue }
    filters: [orders.created_date: "2024"]
  }
  assert: revenue_is_expected_value {
    expression: ${orders.total_revenue} = 626000 ;;
  }
}

O Assert Validator tem os seguintes recursos principais:

Para mais informações e opções de configuração, consulte a página de documentação Validador de declarações de integração contínua.

Gerenciar e executar pacotes de CI

Para gerenciar e executar testes de integração contínua, siga estas etapas:

Por padrão, os Looks e dashboards recebem IDs numéricos ascendentes que são usados no URL do Look ou dashboard. No entanto, não há como manter esses dados sincronizados em todos os sistemas. Portanto, um URL de um painel específico em desenvolvimento não vai apontar para o mesmo painel em controle de qualidade ou produção.

Para UDDs, há uma opção de usar um slug em vez de um ID como parte do URL. O slug é um conjunto de caracteres semialeatório, e não um número. O slug pode ser definido como parte da importação para que um URL semelhante possa apontar para a mesma UDD em desenvolvimento, controle de qualidade e produção. Usar slugs em vez de IDs é uma prática recomendada, principalmente ao clicar em um UDD no Look ou em outro UDD.

Para encontrar o slug, inspecione a saída de gzr dashboard cat. O slug pode ser usado no URL do painel no lugar do ID numérico.

Migrar conteúdo do usuário com o Gazer

Copiar conteúdo, como aparências e painéis, entre o desenvolvimento, o controle de qualidade e a produção costuma ser útil. Talvez você queira produzir conteúdo que mostre novas adições do LookML ou verificar se o conteúdo salvo ainda funciona corretamente após as mudanças no LookML. Nessas situações, o Gazer pode ser usado para copiar conteúdo entre instâncias.

Dashboards do LookML

Os dashboards do LookML são sincronizados entre instâncias durante o fluxo de trabalho regular de CI/CD do LookML. No entanto, se algum UDD estiver sincronizado com painéis do LookML, ele poderá ser atualizado com o Gazer usando o seguinte comando:

gzr dashboard sync_lookml DASHBOARD_ID --host TARGET_SYSTEM_URL

Painéis definidos pelo usuário

Os painéis definidos pelo usuário (UDDs, na sigla em inglês) podem ser migrados com o Gazer referenciando o ID do painel e o URL da instância do Looker em que o UDD está localizado. O Gazer salva a configuração do painel em um arquivo JSON, que é importado para a instância de destino do Looker.

O comando para extrair a configuração do UDD é o seguinte:

gzr dashboard cat DASHBOARD_ID --host TARGET_SYSTEM_URL --dir .

Isso vai gerar um arquivo chamado Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json que contém a configuração do painel.

O UDD pode ser importado para o sistema de destino usando o seguinte comando:

gzr dashboard import Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json FOLDER_ID \
    --host TARGET_SYSTEM_URL

Looks

A migração de aparência funciona de maneira muito semelhante à migração de UDD. Primeiro, use o Gazer para salvar a configuração do Look em um arquivo JSON:

gzr look cat LOOK_ID --host SOURCE_SYSTEM_URL --dir .

Em seguida, importe o Look para a instância de destino:

gzr look import Look_LOOK_ID_LOOK_NAME.json FOLDER_ID \
    --host TARGET_SYSTEM_URL