Integração de CI/CD com Snowflake CLI¶

Snowflake CLI integra-se a plataformas conhecidas de CI/CD (integração contínua e entrega contínua) para que você possa automatizar as implantações do Snowflake para projetos de DCM, aplicativos Snowpark, Snowflake Native Apps e scripts SQL independentes. O Snowflake publica e mantém integrações primárias para os sistemas CI/CD mais utilizados; para qualquer plataforma que possa executar um comando do shell, você também pode instalar a Snowflake CLI diretamente.

Para conceitos de DevOps mais amplos, incluindo gerenciamento de objetos declarativos e estratégia de ambiente, consulte DevOps com Snowflake.

Integrações CI/CD com suporte¶

O Snowflake tem as seguintes integrações CI/CD proprietárias. Cada integração instala a Snowflake CLI no executor e configura a autenticação no Snowflake.


Integração	Status	Autenticação (recomendado)	Referência
Ação GitHub	Versão preliminar pública	Federação de identidades de carga de trabalho (OIDC)	GitHub Action na Snowflake CLI

Nota

Se você usa Jenkins, Bitbucket Pipelines, CircleCI ou algum outro sistema de CI que não está listado na tabela anterior, instale a Snowflake CLI com um único comando do shell em seu pipeline. Consulte instalação da CLI Snowflake em outros sistemas de CI.

Configuração comum do lado do Snowflake¶

Todas as integrações CI/CD proprietárias, siga o mesmo padrão no lado do Snowflake:

Crie um usuário do serviço pelo qual o pipeline autentica.
Configure o método de autenticação do usuário do serviço. A Snowflake recomenda federação de identidade de carga de trabalho (WIF) comOpenID Connect (OIDC) para que nenhum segredo de longa duração seja armazenado na CI do sistema.
Conceda ao usuário do serviço as funções necessárias para implantar os objetos.

Autenticar com federação de identidade de carga de trabalho (OIDC)¶

Com OIDC, o executor da CI obtém um token de identidade de curta duração que o Snowflake valida diretamente. Cada plataforma de CI publica tokens de um emissor distinto com um formato de declaração com assunto diferente; as páginas de referência de integração documentam os valores exatos a serem usados.

Veja a seguir como é uma definição mínima de usuário do serviço. Substitua os valores ISSUER e SUBJECT pelos os valores exigidos na plataforma de CI (consulte a página de referência de integração correspondente).

CREATE USER <username>
  TYPE = SERVICE
  WORKLOAD_IDENTITY = (
    TYPE = OIDC
    ISSUER = '<ci-platform-issuer>'
    SUBJECT = '<ci-platform-subject>'
  );

Para informações sobre o Snowflake WIF, consulte Federação de identidades de carga de trabalho.

Autenticar com um par de chaves ou senha¶

Quando o OIDC não estiver disponível (por exemplo, quando você precisar oferecer suporte a versões de Snowflake CLI mais antigas ou executores da CI no local), use a autenticação de par de chaves. Armazene a chave privada como um segredo de CI e passe-a pelo ambiente usando SNOWFLAKE_PRIVATE_KEY_RAW (para uma conexão temporária) ou SNOWFLAKE_CONNECTIONS_<NAME>_PRIVATE_KEY_RAW (para uma conexão nomeada).

A autenticação de senha é compatível com fluxos de trabalho legados, mas não é recomendada para CI/CD de produção. Consulte Gerenciando conexões Snowflake para ver a lista completa dos parâmetros de autenticação.

Arquivos de configuração e variáveis de ambiente¶

A maioria dos fluxos de trabalho CI/CD combina um config.toml comprometido com segredos injetados por meio de variáveis de ambiente. As seguintes regras de precedência se aplicam:

Os parâmetros de linha de comando substituem tudo.
Variáveis de ambiente voltados a um parâmetro de conexão específico (por exemplo, SNOWFLAKE_CONNECTIONS_MYCONNECTION_PASSWORD) substituem config.toml.
Valores definidos em config.toml são usados quando nenhuma substituição é fornecida.
Variáveis de ambiente genéricas, como SNOWFLAKE_USER, são aplicadas por último.

Para detalhes, incluindo uma referência completa dos parâmetros, consulte:doc:../connecting/configure-connections.

Instalação da Snowflake CLI em outros sistemas de CI¶

Você pode executar a Snowflake CLI em qualquer executor de CI que pode executar um comando do shell. A instalação de linha única canônica usa uv:

uv tool install snowflake-cli
snow --version

Para opções de instalação em sistemas operacionais específicos, consulte Instalação do Snowflake CLI. Para gerenciamento de conexões (incluindo o uso de variáveis de ambiente para evitar o armazenamento de credenciais no executor), consulte Gerenciando conexões Snowflake.

Trabalhos típicos de pipeline¶

A tabela a seguir mapeia trabalhos os comuns de pipeline CI/CD para os comandos da Snowflake CLI que os implementam. Os mesmos comandos funcionam de qualquer sistema de CI.


Trabalho de pipeline	Comando Snowflake CLI	Descrição
Visualizar alterações na solicitação de pull	`snow dcm plan`	Computa um plano de criações, alterações e descartes no ambiente de destino. Publique a saída como um comentário PR para revisão.
Implantar na mesclagem	`snow dcm deploy`	Aplica um conjunto de alterações previamente planejadas ao ambiente de destino.
Execução de scripts Snowpark ou SQL	`snow sql -f <file>`, `snow snowpark deploy`	Executa implantações com script para objetos ainda não cobertos por DCM.
Execução de um objeto de repositório Git	`snow git execute`	Executa arquivos SQL diretamente de uma integração Snowflake Git.

Recomendações de segurança¶

Use federação de identidade de carga de trabalho (OIDC) se o sistema de CI oferecer suporte para isso. Evite armazenar credenciais de longa duração em segredos de CI.
Crie um usuário de serviço dedicado para cada ambiente de pipeline (por exemplo, um usuário por repositório ou por ambiente). Conceda apenas as funções necessárias para esse pipeline.
Use Controle do tráfego de rede com políticas de rede para restringir quais IPs da fonte podem autenticar como o usuário do serviço quando possível.
Não confirme arquivos config.toml com credenciais. Confirme apenas o esqueleto de conexão e forneça segredos por meio de variáveis de ambiente.
Alterne chaves privadas e senhas em um cronograma regular se não puder adotar o OIDC.