CI/CD y DevOps en Snowflake (Parte 1): Una visión completa de funciones y herramientas

DevOps consiste en unir el desarrollo y las operaciones para construir, probar y liberar software de forma más rápida y confiable. Se centra en la automatización, la colaboración y la reducción del riesgo de fallas cuando el software llega a producción. Es una metodología que combina las mejores prácticas de varias áreas con un objetivo claro: automatizar todo lo posible y cubrir cada parte del proceso. El código debe construirse, desplegarse y probarse tantas veces como haga falta. DataOps aplica esa misma mentalidad a los equipos de datos. En lugar de gestionar únicamente código de aplicaciones, DataOps consiste en tratar los pipelines de datos, las transformaciones y los analytics como si fueran software: versionados, probados y desplegados automáticamente. En resumen, es DevOps para el mundo de los datos. Snowflake ya ofrece varias funciones que pueden combinarse para armar pipelines de datos automatizados y gestionar el despliegue de infraestructura. Veámoslas en detalle.

Gestión de cambios declarativa

Una de las primeras cosas que hay que resolver es cómo definir tu infraestructura de Snowflake o de base de datos mediante código. Para eso, Snowflake ofrece una función llamada CREATE OR ALTER, que te permite definir objetos de Snowflake de forma declarativa. Declarativo quiere decir que no tienes que gestionar versiones ni aplicar cambios de manera incremental: solo defines el estado final deseado. Por ejemplo, especificas cómo debe quedar el schema de una tabla, una task o una vista, y Snowflake se ocupa del resto. Compara automáticamente el estado actual con tu definición y aplica solo los cambios necesarios por detrás.

CREATE OR ALTER

Con CREATE OR ALTER basta con escribir un script DDL usando esta palabra clave, y Snowflake se encarga de que, tras la ejecución, tu objeto coincida con el estado definido, sin necesidad de recrearlo. Esto es especialmente importante para objetos como las tablas, donde eliminarlas y volver a crearlas para modificar el schema (por ejemplo, agregar o quitar una columna) podría provocar pérdida de datos. En su lugar, CREATE OR ALTER conserva el estado existente y aplica únicamente los cambios necesarios.

A grandes rasgos, CREATE OR ALTER hace lo siguiente:

• Compara el script con el estado actual en la base de datos
• Genera las sentencias DDL necesarias para actualizar el objeto
• Ejecuta esas sentencias

Snowflake ya admite una amplia variedad de objetos a nivel de base de datos y de cuenta que pueden definirse con CREATE OR ALTER, entre ellos:

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

⠀...y se suman más con regularidad.

EXECUTE IMMEDIATE FROM

Otra función potente de DevOps en Snowflake es EXECUTE IMMEDIATE FROM, que permite ejecutar comandos SQL directamente desde archivos almacenados en un stage interno o en un repositorio de GitHub. Estos archivos pueden contener sentencias SQL estándar o bloques de Snowflake Scripting.

Esta funcionalidad es justo lo que necesitamos para desplegar objetos en Snowflake. En lugar de depender de mecanismos de importación complejos, puedes guardar tus scripts DDL con las definiciones de objetos y ejecutarlos directamente desde el stage: simple y eficiente. Una mejora reciente es el soporte para plantillas Jinja. Con las plantillas Jinja, tus scripts SQL y definiciones DDL pueden volverse mucho más dinámicos, incorporando:

• Variables
• Bucles
• Condiciones
• Macros, entre otros

Por ejemplo, las variables de entorno te permiten parametrizar despliegues y elegir dinámicamente el entorno de destino. Los bucles te permiten iterar sobre usuarios, warehouses o cualquier otro objeto definido, lo que facilita su creación y mantenimiento. Incluso puedes incorporar contenido de otros archivos en stages dentro de tus plantillas. Esto abre todavía más posibilidades.

EXECUTE IMMEDIATE aporta mucho valor cuando estás configurando despliegues automatizados. Entonces, ¿qué nos falta? Sin duda queremos tener nuestros scripts DDL bajo control de versiones. Nunca se sabe lo que puede pasar: necesitas poder revertir cambios, rastrear qué se modificó y ver quién hizo cada cambio. El control de versiones aporta transparencia, trazabilidad y seguridad a tus despliegues.

Integración con GIT

Snowflake también ofrece integración nativa con Git, que te permite almacenar tu código en un repositorio remoto y sincronizarlo con un stage interno. Así, todos tus archivos quedan disponibles para ejecutarse directamente dentro de Snowflake. Aunque la integración con Git actualmente es de solo lectura (con algunas excepciones), cubre otra pieza clave para armar un pipeline de despliegue completo y automatizado.

Probemos a usar la integración con GIT junto con EXECUTE IMMEDIATE para ejecutar un script de creación de usuarios desde el repositorio:

1: Crear el archivo users.sql

CREATE USER joe;
GRANT ROLE developer TO USER joe;

2: Hacer commit de los cambios al repositorio:

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

3: Traer las actualizaciones del repositorio remoto al stage del repositorio en Snowflake

1ALTER GIT REPOSITORY snowflake_git_demo FETCH;

4: Ejecutar el código del archivo en Snowflake

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

Cubrimos esto en detalle en un artículo aparte, que ofrece una visión completa de las capacidades de integración con Git de Snowflake, junto con una guía paso a paso. Vas a aprender:

• Qué es la integración con Git de Snowflake
• Por qué es una función tan interesante
• Cómo usarla para desplegar fácilmente un handler de stored procedure
• Qué operaciones se admiten dentro de Snowflake
• Limitaciones actuales
• Distintos casos de uso para la integración con Git

Ahora que sabemos cómo definir nuestra infraestructura como código, ejecutarla y versionarla, ¿qué nos falta? La última pieza es la orquestación, y tiene dos perspectivas clave:

1. La perspectiva de Snowflake: cómo conectarse, seleccionar los archivos adecuados y ejecutar las consultas. 2. La perspectiva del proceso: cómo encapsular todo en un pipeline independiente que pueda dispararse mediante distintos eventos.

Por ahora, enfoquémonos en la perspectiva de Snowflake. La parte del proceso la abordaremos en la siguiente entrega, donde construiremos un pipeline completo desde cero.

SnowSQL

Es el cliente CLI original de Snowflake, que te permite hacer muchas de las tareas disponibles en la UI: ejecutar consultas, gestionar objetos, importar y exportar datos, etc. Es compatible con los principales sistemas operativos y ofrece varios métodos de autenticación. SnowSQL fue durante años la herramienta de referencia, sobre todo entre los administradores, pero llegó el momento de dar el siguiente paso: Snowflake CLI es el nuevo estándar y debería ser la opción preferida de aquí en adelante, ya que es posible que algunas funcionalidades nunca se sumen a SnowSQL.

Snowflake CLI

Se trata de un proyecto open source, desarrollado inicialmente por la comunidad pero ahora totalmente mantenido por Snowflake. La CLI sirve principalmente como interfaz para desarrolladores para gestionar distintos tipos de código en Snowflake, incluidos stored procedures, funciones, apps nativas y de Streamlit, Snowpark, Snowpark Container Services, repositorios Git y más. Admite una amplia variedad de casos de uso orientados a simplificar la gestión de código e infraestructura en Snowflake. Desde la perspectiva de DevOps, ambas herramientas CLI permiten ejecutar consultas en Snowflake, así que la elección suele depender de la preferencia personal. En nuestro caso, vamos a usar el cliente CLI para conectarnos a Snowflake y realizar las siguientes acciones:

• Sincronizar el stage de Git con el repositorio remoto
• Desplegar el código ejecutando comandos EXECUTE IMMEDIATE para crear objetos de infraestructura como roles, warehouses, bases de datos y más

Repasamos los bloques esenciales que Snowflake aporta en el ámbito de DevOps. Al combinar estas funciones, puedes armar pipelines robustos y automatizados para gestionar tu infraestructura de Snowflake. Sin embargo, las capacidades nativas de Snowflake no son la única opción: existen muchas otras alternativas potentes. Veamos las más populares para tener una visión más completa.

Terraform

Terraform es, posiblemente, la herramienta más adoptada para este propósito. Te permite definir tus objetos de Snowflake como código y gestionarlos del mismo modo que cualquier otra infraestructura cloud. Si ya conoces Infrastructure as Code (IaC), esto te resultará una extensión natural. Para muchos equipos, Terraform es la primera opción, sobre todo si ya lo usan para gestionar su infraestructura cloud. Extender su uso a Snowflake tiene mucho sentido. El proveedor oficial de Snowflake ha madurado mucho con los años y recientemente alcanzó la disponibilidad general (GA). El soporte para nuevos objetos se sigue ampliando de forma continua. Si quieres profundizar en el uso de Terraform con Snowflake, consulta nuestro artículo dedicado al tema.

Permifrost

Permifrost es una herramienta open source diseñada específicamente para gestionar permisos en Snowflake mediante código. Esta herramienta basada en Python te permite definir roles, grants y ownership en archivos YAML. Gestionar privilegios mediante código resulta más escalable y controlado que configurarlos manualmente en la UI o escribir sentencias GRANT en SQL directamente. Permifrost utiliza un modelo declarativo para gestionar permisos en Snowflake. Sin embargo, su alcance es limitado, ya que solo gestiona permisos y roles. No se encarga de la creación ni la eliminación de objetos, por lo que resulta menos completa en comparación con otras alternativas.

Titan

Titan es otra herramienta open source para desplegar infraestructura de Snowflake como código. Escrita en Python, busca resolver algunos de los inconvenientes de Terraform. Por ejemplo, permite cambiar dinámicamente entre roles (SECURITYADMIN vs SYSADMIN, por ejemplo), utiliza definiciones basadas en Python (así no tienes que aprender un lenguaje o una sintaxis nuevos) y admite SQL. Además, no depende de archivos de estado como Terraform.

Eso sí, Titan utiliza los nombres como identificadores únicos, por lo que renombrar un recurso implica la creación de uno nuevo. Y como aún está en desarrollo activo, el soporte para algunos recursos puede ser limitado.

Una nota rápida: el proyecto lo mantiene principalmente una sola persona, que actualmente está enfocada en otros negocios. Tenlo en cuenta al evaluar las opciones.

Schema change

La última quizá sea la más antigua. Es una herramienta imperativa basada en Python, lo que significa que despliegas los cambios como una serie de modificaciones (sentencias ALTER) sobre los objetos originales. Debes mantener scripts versionados y llevar el historial de cómo se han aplicado los cambios. Schema Change aplica entonces solo los nuevos cambios respecto al historial. Por ejemplo, si creas una tabla con Schema Change y más adelante necesitas agregar o quitar una columna, o hacer otras modificaciones, tendrás que escribir un script ALTER con un nuevo número de versión.

Schema Change trabaja con dos tipos de scripts: versionados y repetibles. Los scripts repetibles se despliegan cada vez que se ejecuta la herramienta (si se detecta algún cambio). Este enfoque resulta útil para vistas, donde recrearlas no se considera un cambio destructivo. Otro concepto clave en Schema Change es el historial de scripts aplicados, que se almacena en una tabla de la base de datos.

Veamos un resumen de los pros y los contras de estas herramientas alternativas en una tabla.

Como muestra la tabla, la elección de la herramienta adecuada puede depender de varios factores, como los aspectos que quieras automatizar (infraestructura, permisos o solo scripts SQL), tus conocimientos actuales o los requisitos de la plataforma. Cada herramienta puede encajar bien en distintos escenarios.

En resumen, repasamos las funciones nativas de Snowflake para DevOps, junto con otras alternativas disponibles en el mercado, lo que ofrece una visión completa de las actividades de DevOps en Snowflake. En el próximo artículo profundizaremos en una guía de implementación paso a paso.

Tomáš Sobotík·Senior Data Engineer y Snowflake SME en Norlys

Tomas es un veterano Snowflake Data SuperHero y experto en la materia de Snowflake. Su amplia experiencia en el mundo de los datos abarca más de una década, durante la cual se ha desempeñado como data engineer, arquitecto y administrador de Snowflake en diversos proyectos, sectores y tecnologías. Tomas es un miembro activo de la comunidad, comparte constantemente sus conocimientos e inspira a otros. También es instructor de O'Reilly, donde imparte sesiones de formación en vivo en línea.