CI/CD et DevOps dans Snowflake (Partie 1) : panorama complet des fonctionnalités et outils

Le DevOps vise à rapprocher développement et opérations afin de construire, tester et livrer des logiciels plus vite et avec davantage de fiabilité. Il s'articule autour de l'automatisation, de la collaboration et de la réduction des risques de défaillance en production. C'est une méthodologie qui combine les bonnes pratiques de plusieurs domaines avec un objectif clair : automatiser tout ce qui peut l'être et couvrir l'ensemble du processus. Le code doit être compilé, déployé et testé aussi souvent que nécessaire. Le DataOps applique cette même logique aux équipes data. Au lieu de se limiter à la gestion du code applicatif, le DataOps traite les pipelines de données, les transformations et l'analytique comme du logiciel — versionné, testé et déployé automatiquement. En bref, c'est le DevOps appliqué au monde de la donnée. Snowflake propose déjà plusieurs fonctionnalités qui, combinées, permettent de construire des pipelines de données automatisés et de gérer le déploiement d'infrastructure. Examinons-les en détail.

Gestion déclarative des changements

L'un des premiers chantiers consiste à définir votre infrastructure Snowflake ou base de données sous forme de code. Snowflake propose à cet effet une fonctionnalité appelée CREATE OR ALTER, qui permet de définir les objets Snowflake de manière déclarative. Déclaratif signifie que vous n'avez pas à gérer le versioning ni à appliquer les changements de façon incrémentale : il suffit de définir l'état final souhaité. Vous spécifiez par exemple à quoi doit ressembler un schéma de table, une tâche ou une vue, et Snowflake se charge du reste. La plateforme compare automatiquement l'état actuel à votre définition et n'applique en coulisses que les changements nécessaires.

CREATE OR ALTER

Avec CREATE OR ALTER, il suffit d'écrire un script DDL utilisant ce mot-clé, et Snowflake garantit qu'après exécution, votre objet correspond à l'état défini — sans avoir besoin de le recréer. C'est particulièrement important pour des objets comme les tables, où supprimer puis recréer l'objet pour en modifier le schéma (par exemple ajouter ou retirer une colonne) pourrait entraîner une perte de données. CREATE OR ALTER préserve l'état existant et n'applique que les changements nécessaires.

De manière générale, CREATE OR ALTER procède ainsi :

• Compare le script avec l'état actuel de la base de données
• Génère les instructions DDL nécessaires pour mettre à jour l'objet
• Exécute ces instructions

Snowflake prend déjà en charge un large éventail d'objets de base de données et de compte définissables avec CREATE OR ALTER, notamment :

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

⠀…et d'autres s'ajoutent régulièrement !

EXECUTE IMMEDIATE FROM

Autre fonctionnalité DevOps puissante de Snowflake : EXECUTE IMMEDIATE FROM. Elle permet d'exécuter des commandes SQL directement depuis des fichiers stockés dans un stage interne ou un dépôt GitHub. Ces fichiers peuvent contenir des instructions SQL standard ou des blocs Snowflake Scripting.

C'est exactement ce qu'il nous faut pour déployer des objets dans Snowflake. Plutôt que de recourir à des mécanismes d'import complexes, vous stockez vos scripts DDL contenant les définitions d'objets et vous les exécutez directement depuis le stage — simple et efficace. Amélioration récente : la prise en charge du templating Jinja. Les templates Jinja rendent vos scripts SQL et définitions DDL bien plus dynamiques grâce à :

• Des variables
• Des boucles
• Des conditions
• Des macros, et bien plus encore

Les variables d'environnement, par exemple, permettent de paramétrer les déploiements et de choisir dynamiquement l'environnement cible. Les boucles permettent d'itérer sur des utilisateurs, des warehouses ou tout autre objet défini, ce qui facilite leur création et leur maintenance. Vous pouvez même intégrer dans vos templates le contenu d'autres fichiers présents dans les stages. De quoi élargir encore le champ des possibles.

EXECUTE IMMEDIATE apporte une réelle valeur ajoutée pour mettre en place des déploiements automatisés. Que nous faut-il ensuite ? À l'évidence, nos scripts DDL doivent être placés sous contrôle de version. On ne sait jamais ce qui peut arriver : il faut pouvoir revenir en arrière, savoir ce qui a été modifié et par qui. Le contrôle de version apporte transparence, traçabilité et sécurité à vos déploiements.

Intégration GIT

Snowflake propose également une intégration Git native, qui permet de stocker votre code dans un dépôt distant et de le synchroniser avec un stage interne. Tous vos fichiers deviennent ainsi exécutables directement depuis Snowflake. Bien que l'intégration Git soit actuellement en lecture seule (à quelques exceptions près), elle comble une autre brique manquante pour construire un pipeline de déploiement complet et automatisé.

Essayons d'utiliser l'intégration GIT avec EXECUTE IMMEDIATE pour exécuter un script de création d'utilisateur depuis le dépôt :

1 : Créer le fichier users.sql

CREATE USER joe;
GRANT ROLE developer TO USER joe;

2 : Committer les modifications dans le dépôt :

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

3 : Récupérer les mises à jour depuis le dépôt distant vers le stage Snowflake

1ALTER GIT REPOSITORY snowflake_git_demo FETCH;

4 : Exécuter le code du fichier dans Snowflake

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

Nous avons traité ce sujet en détail dans un article dédié, qui offre un panorama complet des capacités d'intégration Git de Snowflake, accompagné d'un guide pas à pas. Vous y découvrirez :

• Ce qu'est l'intégration Git de Snowflake
• Pourquoi c'est une fonctionnalité particulièrement intéressante
• Comment l'utiliser pour déployer facilement un handler de procédure stockée
• Les opérations prises en charge dans Snowflake
• Les limitations actuelles
• Différents cas d'usage de l'intégration Git

Maintenant que nous savons définir notre infrastructure en tant que code, l'exécuter et la versionner, que manque-t-il encore ? La dernière pièce du puzzle, c'est l'orchestration — sous deux angles clés :

1. Le point de vue Snowflake – comment se connecter, sélectionner les bons fichiers et exécuter les requêtes 2. Le point de vue processus – comment encapsuler le tout dans un pipeline autonome déclenchable par différents événements

Concentrons-nous pour l'instant sur le point de vue Snowflake. Nous aborderons le volet processus dans la prochaine partie, où nous construirons un pipeline complet à partir de zéro.

SnowSQL

C'est le client CLI Snowflake historique, qui permet de réaliser la plupart des tâches accessibles depuis l'interface : exécuter des requêtes, gérer les objets, importer/exporter des données, etc. Il prend en charge tous les principaux systèmes d'exploitation et propose plusieurs méthodes d'authentification. SnowSQL a été l'outil de référence pendant des années, en particulier côté administrateurs, mais il est temps de tourner la page : la CLI Snowflake est le nouveau standard et doit désormais être privilégiée, car certaines fonctionnalités risquent de ne plus être ajoutées à SnowSQL.

CLI Snowflake

C'est un projet open source, lancé à l'origine par la communauté mais désormais entièrement maintenu par Snowflake. La CLI sert principalement d'interface développeur pour gérer différents types de code dans Snowflake : procédures stockées, fonctions, applications natives et Streamlit, Snowpark, Snowpark Container Services, dépôts Git, et bien plus. Elle couvre un large éventail de cas d'usage destinés à simplifier la gestion du code et de l'infrastructure dans Snowflake. D'un point de vue DevOps, les deux outils CLI permettent d'exécuter des requêtes dans Snowflake, et le choix relève donc souvent de la préférence personnelle. Dans notre cas, nous utiliserons la CLI pour nous connecter à Snowflake et effectuer les actions suivantes :

• Synchroniser le stage Git avec le dépôt distant
• Déployer le code en exécutant des commandes EXECUTE IMMEDIATE pour créer des objets d'infrastructure tels que des rôles, warehouses, bases de données, etc.

Nous avons couvert les briques essentielles que Snowflake propose dans l'univers du DevOps. En les combinant, vous pouvez construire des pipelines robustes et automatisés pour gérer votre infrastructure Snowflake. Cela dit, les capacités natives de Snowflake ne sont pas la seule option : il existe de nombreuses alternatives intéressantes. Passons en revue les plus populaires pour brosser un tableau plus complet.

Terraform

Terraform est sans doute l'outil le plus largement adopté dans ce domaine. Il permet de définir vos objets Snowflake sous forme de code et de les gérer comme n'importe quelle autre infrastructure cloud. Si vous connaissez déjà l'Infrastructure as Code (IaC), cela vous semblera une extension naturelle. Pour de nombreuses équipes, Terraform est le premier choix — surtout si vous l'utilisez déjà pour votre infrastructure cloud. Étendre son usage à Snowflake va de soi. Le provider Snowflake officiel a beaucoup mûri au fil des années et a récemment atteint la disponibilité générale. La prise en charge de nouveaux objets s'enrichit en continu. Pour approfondir l'usage de Terraform avec Snowflake, consultez notre article dédié.

Permifrost

Permifrost est un outil open source spécialement conçu pour gérer les permissions dans Snowflake via du code. Écrit en Python, il permet de définir rôles, grants et propriétaires dans des fichiers YAML. Gérer les privilèges par le code offre une approche bien plus scalable et maîtrisée que la configuration manuelle dans l'interface ou l'écriture de grants SQL bruts. Permifrost s'appuie sur un modèle déclaratif pour gérer les permissions dans Snowflake. Sa portée reste toutefois limitée, puisqu'il ne traite que les permissions et les rôles. Il ne gère ni la création ni la suppression d'objets, ce qui le rend moins complet que d'autres alternatives.

Titan

Titan est un autre outil open source pour déployer l'infrastructure Snowflake sous forme de code. Écrit en Python, il cherche à pallier certains inconvénients de Terraform. Il permet par exemple de basculer dynamiquement entre les rôles (SECURITYADMIN et SYSADMIN, par exemple), s'appuie sur des définitions en Python (donc pas besoin d'apprendre un nouveau langage ni une nouvelle syntaxe) et prend en charge le SQL. Autre atout : il ne dépend pas de fichiers d'état comme Terraform.

En revanche, Titan utilise les noms comme identifiants uniques : renommer une ressource entraîne donc la création d'une nouvelle ressource. Titan étant encore en développement actif, la prise en charge de certaines ressources peut être limitée.

Petite précision : le projet est principalement maintenu par une seule personne, actuellement mobilisée sur d'autres activités. À garder en tête au moment d'évaluer les options.

Schema change

Le dernier est peut-être le plus ancien. C'est un outil impératif basé sur Python : vous déployez les changements sous forme d'une série de modifications (instructions ALTER) appliquées aux objets d'origine. Vous devez maintenir des scripts versionnés et suivre l'historique de l'application des changements. Schema Change applique alors uniquement les nouveaux changements par rapport à cet historique. Par exemple, si vous créez une table avec Schema Change puis devez ajouter ou supprimer une colonne, ou effectuer d'autres modifications, vous devrez écrire un script ALTER avec un nouveau numéro de version.

Schema Change fonctionne avec deux types de scripts : versionnés et répétables. Les scripts répétables sont déployés à chaque exécution de l'outil (si un changement est détecté). Cette approche est utile pour les vues, où recréer la vue n'est pas considéré comme un changement destructif. Autre concept clé de Schema Change : l'historique des scripts appliqués, stocké dans une table de la base de données.

Essayons de résumer les avantages et inconvénients de ces outils alternatifs dans un tableau.

Comme le montre le tableau, le bon choix d'outil dépend de nombreux facteurs : les aspects à automatiser (infrastructure, permissions ou simples scripts SQL), vos connaissances actuelles ou encore les exigences de la plateforme. Chaque outil peut s'avérer pertinent selon le contexte.

Pour conclure, nous avons passé en revue les fonctionnalités natives de Snowflake pour le DevOps ainsi que les principales alternatives disponibles sur le marché, pour offrir un panorama complet des activités DevOps dans Snowflake. Dans le prochain article, place à un guide de mise en œuvre pas à pas !

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

Tomas est un Snowflake Data SuperHero de longue date et un expert reconnu de Snowflake. Son expérience dans le monde de la donnée s'étend sur plus d'une décennie, durant laquelle il a occupé les rôles de data engineer, architecte et administrateur Snowflake sur des projets variés, dans de nombreux secteurs et avec des technologies très diverses. Tomas est un membre central de la communauté, partageant activement son expertise et inspirant les autres. Il est également formateur O'Reilly et anime des sessions de formation en ligne en direct.