No post anterior, falamos sobre vários recursos de DevOps no Snowflake. Eles funcionam como blocos de construção para manter sua infraestrutura no Snowflake como código e de forma automatizada.
Neste post, o foco é combinar esses recursos para montar pipelines de CI/CD que fazem o deploy automatizado da infraestrutura no Snowflake usando recursos nativos como CREATE OR ALTER, integração com Git e EXECUTE IMMEDIATE FROM. Usamos o GitHub como serviço de repositório e o GitHub Actions como orquestrador.
Vamos começar com uma breve introdução aos workflows do GitHub Actions.
Workflows do GitHub Actions
O GitHub Actions é uma plataforma robusta de CI/CD integrada diretamente ao GitHub, que permite aos desenvolvedores automatizar fluxos de software por meio de pipelines orientados a eventos. Ela usa o conceito de workflows definidos em arquivos YAML, armazenados no diretório .github/workflows/ do seu repositório. Cada workflow pode conter um ou mais jobs, executados em máquinas virtuais chamadas runners. Esses runners podem ser hospedados pelo próprio GitHub, então você não precisa gerenciar nada. Um runner é atribuído automaticamente ao seu pipeline assim que o workflow é disparado, ou você pode usar um runner self-hosted.
Para criar um pipeline, é preciso definir alguns elementos essenciais:
Gatilho (trigger)
Pode ser um evento no repositório (por exemplo, push, pull_request etc.), um job agendado via cron ou um gatilho manual.
Ambiente do runner
Define onde seu código vai rodar — o sistema operacional do runner. Exemplos comuns: ubuntu-latest ou windows-latest.
Estrutura da automação
Depois, é hora de definir a automação em si: uma sequência de etapas que precisam ser executadas. Lembre-se de que, toda vez que seu código roda, a máquina do runner começa em um estado padrão e limpo. Ou seja, você precisa preparar o ambiente para o seu job — instalando as linguagens necessárias (Python, por exemplo), baixando o código do repositório e lendo variáveis de ambiente. Cada etapa pode conter comandos de shell, execução de scripts ou ações prontas. As etapas também podem aproveitar informações contextuais, como ${{ github.event_name }} ou ${{ secrets.SF_ACCOUNT_ID }}.
Essas características tornam o GitHub Actions uma ótima opção para rodar pipelines de CI/CD em que você precisa gerenciar credenciais de banco de dados com segurança, executar scripts SQL, fazer deploy de mudanças entre ambientes e rastrear quem alterou o quê — tudo com integração nativa de controle de versão.
Pipeline de CI/CD no Snowflake para a infraestrutura da conta
Vamos trabalhar localmente no VS Code, onde desenvolvemos os scripts SQL e a definição YAML do workflow do GitHub Actions. Com tudo pronto, fazemos o push das alterações para o repositório remoto, abrimos um pull request e mesclamos na nossa branch dev. Como mostra o diagrama, vamos aproveitar vários recursos do Snowflake para isso. Também vamos criar duas versões do pipeline de CI/CD:
1 Usando a extensão Git no Snowflake Nessa abordagem, o GitHub Actions atua apenas como orquestrador. Graças à extensão Git, conseguimos rodar todo o código diretamente dentro do Snowflake.
2 Executando o código em um runner do GitHub com o SnowCLI Se você prefere não usar a extensão Git no Snowflake, existe uma alternativa: executar o código direto na máquina do runner pelo Snowflake Command Line Interface ( SnowCLI). Vamos cobrir essa opção também.
Criação da infraestrutura no Snowflake
Vamos criar nossa infraestrutura primeiro e armazená-la em vários arquivos sql.
Nossos warehouses:
USE ROLE sysadmin;
--ELT warehouse definition
CREATE WAREHOUSE IF NOT EXISTS elt WITH
WAREHOUSE_SIZE = XSMALL
AUTO_SUSPEND = 60
AUTO_RESUME = True
INITIALLY_SUSPENDED = True;
--developers warehouse definition
CREATE WAREHOUSE IF NOT EXISTS developers WITH
WAREHOUSE_SIZE = SMALL
AUTO_SUSPEND = 120
AUTO_RESUME = True
INITIALLY_SUSPENDED = True;
Também precisamos de uma role:
/*
* Role name: LOADER
* Description: Used by ELT pipelines to load data */
*/
USE ROLE securityadmin;
CREATE OR ALTER ROLE loader;
E, por fim, o banco de dados e o schema:
/*
* DB name: DEVOPS
* Description: Used for showcasing Snowflake DevOps capabilities
*/
use role sysadmin;
create or alter database devops;
------------------------SCHEMAS------------------------
/*
* Schema name: ADMIN
* Description: To keep all admin stuff at one place
*/
Expandir código
Pipeline de CI/CD usando o Git Stage
Os scripts SQL iniciais já estão prontos. Agora é hora de desenvolver o workflow do GitHub Actions. Ele se apoia na extensão Git no Snowflake e depende de uma integração ativa entre sua conta Snowflake e seu repositório no GitHub. Já mostramos como configurar essa integração em um post dedicado à ~ integração Git do Snowflake ~.
name: Deploying Snowflake objects with CLI v1
env:
SNOWFLAKE_ACCOUNT: ${{ secrets.SF_ACCOUNT }}
SNOWFLAKE_USER: ${{ secrets.SF_USER }}
SNOWFLAKE_PASSWORD: ${{ secrets.SF_PASSWORD }}
SNOWFLAKE_DATABASE: ${{ secrets.SF_DATABASE }}
SNOWFLAKE_SCHEMA: ${{ secrets.SF_SCHEMA }}
SNOWFLAKE_ROLE: ${{ secrets.SF_ROLE }}
SNOWFLAKE_WAREHOUSE: ${{ secrets.SF_WAREHOUSE }}
on:
workflow_dispatch:
jobs:
deploy-Snowflake-changes:
Expandir código
Vamos percorrer o código e explicar o que ele faz.
No começo, configuramos as variáveis de ambiente necessárias para se conectar ao Snowflake. Esses valores vêm do GitHub Secrets. Em seguida, definimos o gatilho — neste caso, usamos workflow_dispatch, ou seja, o workflow precisa ser disparado manualmente a partir do repositório.
O resto é bem direto. Precisamos instalar o SnowCLI na máquina do runner do GitHub para conseguir:
- conectar ao Snowflake
- disparar os comandos necessários
Existe uma ~ GitHub Action ~ nativa, fornecida pelo Snowflake, que simplifica a configuração e o gerenciamento da conexão.
Primeiro, sincronizamos o stage do repositório Git no Snowflake com o repositório remoto usando o comando ALTER GIT REPOSITORY. Isso traz as alterações mais recentes direto para o Git stage dentro do Snowflake.
Depois, usamos EXECUTE IMMEDIATE para rodar o código diretamente dos arquivos SQL. Vamos fazer o deploy de warehouses, roles e bancos de dados com seus schemas. E é isso — um workflow simples e eficaz para fazer o deploy automático das alterações na sua infraestrutura no Snowflake como código.
Pipeline de CI/CD executando o código no runner do GitHub
Vamos montar um pipeline parecido, mas, desta vez, executando tudo direto na máquina do runner do GitHub, sem usar o Git stage do Snowflake. O Git stage é um recurso poderoso, mas ainda tem algumas limitações — é somente leitura e não acessa repositórios atrás de redes privadas, por exemplo. Essas restrições podem ser motivo suficiente para evitar a integração Git do Snowflake em certos cenários. Esta é a nossa definição de workflow YAML:
name: Deploying Snowflake objects with cli v2
env:
SNOWFLAKE_ACCOUNT: ${{ secrets.SF_ACCOUNT }}
SNOWFLAKE_USER: ${{ secrets.SF_USER }}
SNOWFLAKE_PASSWORD: ${{ secrets.SF_PASSWORD }}
SNOWFLAKE_DATABASE: ${{ secrets.SF_DATABASE }}
SNOWFLAKE_SCHEMA: ${{ secrets.SF_SCHEMA }}
SNOWFLAKE_ROLE: ${{ secrets.SF_ROLE }}
SNOWFLAKE_WAREHOUSE: ${{ secrets.SF_WAREHOUSE }}
on:
workflow_dispatch:
jobs:
deploy-Snowflake-changes:
name: Snowflake infrastructure deployment
Expandir código
Vamos focar nas diferenças em relação à versão anterior. Desta vez, precisamos trazer o código do repositório remoto para a máquina do runner. Para isso, usamos outra action chamada checkout, que basicamente puxa o código do repositório remoto.
Em seguida, usamos o SnowCLI de novo, mas agora rodando o código a partir dos arquivos armazenados na máquina do runner, em vez dos arquivos no stage do repositório.
Melhorias
Este foi um exemplo simples de como desenvolver um pipeline básico de CI/CD para fazer o deploy de infraestrutura no Snowflake. Há bastante espaço para deixá-lo mais "production ready". Em um ambiente real, você teria:
- pipelines diferentes para cada ambiente (dev, prod)
- gatilhos em eventos de push e pull request limitados a branches específicas
- etapas diferentes em eventos de push e de pull request
Seria ótimo ter uma etapa de "plan", como no Terraform, mostrando quais recursos serão criados, atualizados ou excluídos antes que as alterações sejam aplicadas. Espero ver uma funcionalidade parecida nesses recursos nativos do Snowflake.
Para fechar
Este post mostrou como usar os recursos nativos de DevOps do Snowflake para integração e deploy contínuos. Implementamos um pipeline de CI/CD com um workflow do GitHub Actions para fazer o deploy de objetos de infraestrutura do Snowflake como código diretamente do nosso repositório remoto — bastando enviar atualizações da máquina local para o repositório.
Esta é a parte final da nossa série dedicada a DevOps no Snowflake. Cobrimos o tema em três posts:
- Um mergulho profundo na integração Git do Snowflake
- CI/CD e DevOps no Snowflake (Parte 1): Visão abrangente de recursos e ferramentas
- CI/CD e DevOps no Snowflake (Parte 2): 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 um especialista de referência em Snowflake. Sua experiência no mundo dos dados se estende por mais de uma década, durante a qual atuou como data engineer, arquiteto e admin do Snowflake em diversos projetos, setores e tecnologias. Tomas é um membro ativo da comunidade, sempre compartilhando seu conhecimento e inspirando outras pessoas. Também é instrutor da O'Reilly, conduzindo treinamentos ao vivo online.