CI/CD e DevOps no Snowflake (Parte 1): Visão Geral Completa de Recursos e Ferramentas

DevOps tem tudo a ver com aproximar desenvolvimento e operações para construir, testar e lançar software de forma mais rápida e confiável. O foco está em automação, colaboração e em reduzir o risco de falhas quando o software chega à produção. É uma metodologia que combina boas práticas de várias áreas com um objetivo claro: automatizar tudo o que for possível e cobrir todas as etapas do processo. O código deve ser buildado, implantado e testado quantas vezes for necessário. O DataOps aplica essa mesma mentalidade aos times de dados. Em vez de gerenciar apenas o código de aplicação, o DataOps trata pipelines de dados, transformações e analytics como software — versionados, testados e implantados de forma automática. Em resumo: é DevOps para o mundo dos dados. O Snowflake já oferece uma série de recursos que, combinados, permitem construir pipelines de dados automatizados e gerenciar o deploy da infraestrutura. Vamos olhar esses recursos com mais detalhes.

Gestão Declarativa de Mudanças

Uma das primeiras coisas que você precisa resolver é definir sua infraestrutura no Snowflake ou no banco de dados como código. Para isso, o Snowflake oferece o recurso CREATE OR ALTER, que permite definir objetos do Snowflake de forma declarativa. Declarativo significa que você não precisa gerenciar versionamento nem aplicar mudanças de forma incremental — basta definir o estado final desejado. Por exemplo: você especifica como uma schema de tabela, task ou view deve ficar, e o Snowflake cuida do resto. Ele compara automaticamente o estado atual com a sua definição e aplica apenas as mudanças necessárias por trás dos panos.

CREATE OR ALTER

Com o CREATE OR ALTER, basta escrever um script DDL usando essa palavra-chave, e o Snowflake garante que, após a execução, o seu objeto vai estar no estado definido — sem precisar recriá-lo. Isso é especialmente importante para objetos como tabelas, em que dropar e recriar para alterar o schema (por exemplo, adicionar ou remover uma coluna) poderia causar perda de dados. Em vez disso, o CREATE OR ALTER preserva o estado existente e aplica somente as mudanças necessárias.

Em alto nível, o CREATE OR ALTER faz o seguinte:

• Compara o script com o estado atual no banco de dados
• Gera os comandos DDL necessários para atualizar o objeto
• Executa esses comandos

O Snowflake já suporta uma ampla variedade de objetos de banco de dados e de conta que podem ser definidos com CREATE OR ALTER, incluindo:

• Warehouse
• Database
• Schema
• Table
• View
• Stage
• Role
• Database Role
• Application
• Function
• External Function
• Procedure

⠀...e novos são adicionados com frequência!

EXECUTE IMMEDIATE FROM

Outro recurso poderoso de DevOps no Snowflake é o EXECUTE IMMEDIATE FROM. Ele permite executar comandos SQL diretamente a partir de arquivos armazenados em um stage interno ou em um repositório do GitHub. Esses arquivos podem conter comandos SQL padrão ou blocos de Snowflake Scripting.

É exatamente isso que precisamos para fazer o deploy de objetos no Snowflake. Em vez de depender de mecanismos complexos de importação, você armazena seus scripts DDL com as definições de objetos e os executa direto do stage — simples e eficiente. Uma melhoria recente desse recurso é o suporte a templates Jinja. Com Jinja, dá para deixar seus scripts SQL e definições DDL muito mais dinâmicos, incorporando:

• Variáveis
• Loops
• Condicionais
• Macros, entre outros

Por exemplo, variáveis de ambiente permitem parametrizar deployments e escolher dinamicamente o ambiente de destino. Loops permitem iterar sobre usuários, warehouses ou quaisquer outros objetos definidos, facilitando a criação e a manutenção. Você pode até puxar conteúdo de outros arquivos em stages dentro dos seus templates. Isso abre ainda mais possibilidades.

O EXECUTE IMMEDIATE agrega bastante valor na hora de montar deployments automatizados. E o próximo passo? Com certeza queremos ter nossos scripts DDL sob controle de versão. Nunca se sabe o que pode acontecer — você precisa ser capaz de reverter mudanças, rastrear o que foi modificado e ver quem fez cada alteração. O controle de versão traz transparência, responsabilidade e segurança para seus deployments.

Integração com GIT

O Snowflake também oferece integração nativa com Git, que permite armazenar seu código em um repositório remoto e sincronizá-lo com um stage interno. Assim, todos os seus arquivos ficam disponíveis para execução diretamente dentro do Snowflake. Embora a integração com Git seja, no momento, somente leitura (com algumas exceções), ela preenche mais uma lacuna na construção de um pipeline de deploy completo e automatizado.

Vamos tentar usar a integração com GIT junto com o EXECUTE IMMEDIATE para rodar um script de criação de usuário a partir do repositório:

1: Crie o arquivo users.sql

CREATE USER joe;
GRANT ROLE developer TO USER joe;

2: Faça commit das alterações no repositório:

git add users.sql
git commit -m "Adding new user"
git push

3: Busque as atualizações do repositório remoto para o stage do repositório no Snowflake

1ALTER GIT REPOSITORY snowflake_git_demo FETCH;

4: Execute o código do arquivo no Snowflake

1EXECUTE IMMEDIATE FROM @snowflake_git_demo/branches/main/sql/users.sql;

Tratamos disso em detalhes em um post à parte, que traz uma visão abrangente dos recursos de integração com Git do Snowflake, além de um guia passo a passo. Você vai aprender:

• O que é a integração com Git do Snowflake
• Por que é um recurso tão interessante
• Como usá-la para fazer o deploy de um handler de stored procedure com facilidade
• Quais operações são suportadas dentro do Snowflake
• Limitações atuais
• Diversos casos de uso para a integração com Git

Agora que já sabemos como definir nossa infraestrutura como código, executá-la e versioná-la, o que ainda falta? A peça final é a orquestração — e ela tem duas perspectivas-chave:

1. A perspectiva do Snowflake – como se conectar, selecionar os arquivos certos e executar as queries 2. A perspectiva do processo – como empacotar tudo isso em um pipeline independente que possa ser disparado por diferentes eventos

Por enquanto, vamos focar na perspectiva do Snowflake. Cobriremos o lado do processo na próxima parte, quando vamos construir um pipeline completo do zero.

SnowSQL

É o cliente CLI original do Snowflake, que permite executar muitas das tarefas disponíveis na UI — rodar queries, gerenciar objetos, importar/exportar dados etc. Ele suporta todos os principais sistemas operacionais e oferece vários métodos de autenticação. O SnowSQL foi a ferramenta de referência por muitos anos, especialmente entre admins, mas chegou a hora de seguir em frente — o Snowflake CLI é o novo padrão e deve ser a escolha preferida daqui pra frente, já que pode haver funcionalidades que não serão adicionadas ao SnowSQL.

Snowflake CLI

É um projeto open-source, inicialmente desenvolvido pela comunidade, mas hoje totalmente mantido pelo Snowflake. O CLI serve principalmente como uma interface para desenvolvedores gerenciarem diferentes tipos de código no Snowflake — incluindo stored procedures, functions, native apps e Streamlit apps, Snowpark, Snowpark Container Services, repositórios Git e mais. Ele cobre uma ampla gama de casos de uso voltados a simplificar a gestão de código e infraestrutura dentro do Snowflake. Do ponto de vista de DevOps, as duas CLIs permitem rodar queries no Snowflake, então a escolha costuma ser uma questão de preferência pessoal. No nosso caso, vamos usar a CLI para conectar ao Snowflake e executar as seguintes ações:

• Sincronizar o stage do Git com o repositório remoto
• Fazer o deploy do código rodando comandos EXECUTE IMMEDIATE para criar objetos de infraestrutura como roles, warehouses, databases e mais

Já passamos pelos blocos essenciais que o Snowflake oferece no universo DevOps. Combinando esses recursos, dá para construir pipelines robustos e automatizados para gerenciar sua infraestrutura no Snowflake. Mas os recursos nativos do Snowflake não são a única opção — existem várias outras alternativas poderosas. Vamos dar uma olhada nas mais populares para ter um panorama mais completo.

Terraform

O Terraform é, provavelmente, a ferramenta mais adotada para esse propósito. Ele permite definir seus objetos do Snowflake como código e gerenciá-los da mesma forma que qualquer outra infraestrutura de nuvem. Se você já conhece Infraestrutura como Código (IaC), vai parecer uma extensão natural. Para muitos times, o Terraform é a primeira escolha — especialmente se você já o usa para gerenciar sua infraestrutura de nuvem. Estender o uso ao Snowflake faz todo o sentido. O provider oficial do Snowflake amadureceu muito ao longo dos anos e recentemente atingiu General Availability. O suporte a novos objetos é ampliado continuamente. Se quiser se aprofundar no uso do Terraform com Snowflake, confira nosso post dedicado sobre o assunto.

Permifrost

O Permifrost é uma ferramenta open-source criada especificamente para gerenciar permissões no Snowflake via código. Essa ferramenta baseada em Python permite definir roles, grants e ownership em arquivos YAML. Gerenciar privilégios por código é uma abordagem mais escalável e controlada do que configurá-los manualmente na UI ou escrever grants SQL na mão. O Permifrost usa um modelo declarativo para gerenciar permissões no Snowflake. No entanto, seu escopo é limitado: ele lida apenas com permissões e roles. Não gerencia criação nem exclusão de objetos, o que o torna menos abrangente do que outras alternativas.

Titan

O Titan é outra ferramenta open-source para fazer o deploy de infraestrutura do Snowflake como código. Escrito em Python, busca resolver algumas das limitações do Terraform. Por exemplo: permite alternar dinamicamente entre roles (como SECURITYADMIN vs SYSADMIN), usa definições em Python (ou seja, sem precisar aprender uma nova linguagem ou sintaxe) e suporta SQL. Além disso, não depende de arquivos de state como o Terraform.

Por outro lado, o Titan usa nomes como identificadores únicos, então renomear um recurso resulta na criação de um novo. E, como ainda está em desenvolvimento ativo, o suporte a alguns recursos pode ser limitado.

Vale uma observação rápida: o projeto é mantido principalmente por uma pessoa que, no momento, está focada em outras frentes. Leve isso em conta ao avaliar as opções.

Schema change

O último talvez seja o mais antigo. É uma ferramenta imperativa baseada em Python, ou seja, você faz o deploy das mudanças como uma série de modificações (comandos ALTER) sobre os objetos originais. É preciso manter scripts versionados e rastrear o histórico de como as mudanças foram aplicadas. O Schema Change então aplica apenas as novas mudanças em relação ao histórico. Por exemplo: se você cria uma tabela com o Schema Change e depois precisa adicionar/remover uma coluna ou fazer outras modificações, vai ter que escrever um script ALTER com um novo número de versão.

O Schema Change trabalha com dois tipos de scripts: versionados e repetíveis. Os scripts repetíveis são implantados toda vez que a ferramenta roda (se a mudança for detectada). Essa abordagem é útil para views, em que recriar a view não é considerada uma mudança destrutiva. Outro conceito-chave do Schema Change é o histórico de scripts aplicados, que fica armazenado em uma tabela do banco de dados.

Vamos tentar resumir os prós e contras dessas ferramentas alternativas em uma tabela.

Como mostra a tabela, a escolha da ferramenta certa pode depender de vários fatores, como os aspectos que você quer automatizar (infraestrutura, permissões ou apenas scripts SQL), seu conhecimento atual ou requisitos de plataforma. Cada ferramenta pode se encaixar bem em cenários diferentes.

Para fechar, passamos pelos recursos nativos do Snowflake para DevOps, junto com outras alternativas disponíveis no mercado, oferecendo uma visão abrangente das atividades de DevOps no Snowflake. No próximo post, vamos mergulhar em um guia de implementação passo a passo!

Tomáš Sobotík·Senior Data Engineer & Snowflake SME na Norlys

Tomas é um Snowflake Data SuperHero de longa data e especialista geral em Snowflake. Sua vasta experiência no mundo de dados passa de uma década, período em que atuou como data engineer, arquiteto e admin do Snowflake em projetos diversos, em diferentes setores e tecnologias. Tomas é um membro ativo da comunidade, compartilhando seu conhecimento e inspirando outras pessoas. Também é instrutor da O'Reilly, conduzindo treinamentos online ao vivo.