Plongée dans l'intégration Git de Snowflake

L'intégration Git de Snowflake permet de relier nativement votre compte Snowflake à l'une des plateformes Git prises en charge (GitHub, GitLab, etc.) et de synchroniser le contenu d'un dépôt distant avec votre compte. Pour cette synchronisation, Snowflake utilise un type de stage particulier : le repository stage. Celui-ci est ensuite synchronisé avec le dépôt Git distant et devient un dépôt local contenant un clone complet du dépôt distant, avec tout ce que l'on peut attendre — branches, commits, etc.

Grâce à cette synchronisation, vous disposez d'un clone complet du dépôt directement dans votre compte Snowflake. Vous pouvez exploiter les fichiers récupérés dans vos applications Snowflake ou écrire des UDF / procédures stockées dont le code handler réside dans un dépôt Git distant et reste synchronisé avec le repository stage. Vous gardez ainsi facilement le code sous gestion de version et il suffit de rafraîchir le stage à chaque mise à jour du dépôt.

Vous pouvez également utiliser n'importe quel fichier issu de n'importe quelle branche ou commit directement dans Snowflake.

Cette intégration simplifie le cycle de développement de votre code dès lors que vous souhaitez le versionner. Prenons l'exemple du code handler d'une procédure stockée. Avant cette intégration, vous deviez gérer la version de votre côté, en dehors de Snowflake. Vous écriviez et testiez votre code handler dans VS Code. Une fois le développement terminé, il fallait pousser les modifications dans un dépôt distant pour les versionner. En parallèle, il fallait aussi déployer le code dans Snowflake et créer une procédure stockée utilisant ce code comme handler.

Concrètement, il fallait soit téléverser le code manuellement dans un stage Snowflake puis créer la procédure stockée, soit s'appuyer sur la Snowflake CLI pour gérer à la fois le téléversement et la création de la procédure. Dans les deux cas, c'était une étape supplémentaire déconnectée de votre code versionné. À chaque modification, il fallait recommencer tout le processus — développer le code, le committer dans le dépôt, puis mettre à jour le fichier handler dans Snowflake.

Voyons comment l'intégration Git native fluidifie tout cela. Puisque le code handler peut être référencé directement dans le repository stage, dès que vous committez des modifications et synchronisez ce stage, le handler de la procédure stockée est automatiquement mis à jour tout en restant versionné. Fini les processus séparés (gestion de version et mise à jour des procédures stockées) : un seul workflow, rationalisé.

L'intégration Git de Snowflake permet de connecter des dépôts Git issus des plateformes suivantes :

• GitHub
• GitLab
• BitBucket
• Azure DevOps
• AWS CodeCommit

Dans cet exemple, nous allons écrire un simple handler de procédure stockée Hello World en Python, pousser les modifications dans un dépôt GitHub distant et l'importer dans Snowflake via l'intégration Git. Nous modifierons ensuite le code handler pour constater à quel point sa mise à jour dans Snowflake est facilitée par l'intégration Git. Commençons par un schéma simple illustrant ce que nous allons construire :

1. D'abord, nous développons le code handler localement dans VS Code et le poussons dans un dépôt GitHub.
2. Ensuite, nous créons un repository stage dans Snowflake, qui pointe vers le dépôt distant. Il faut également créer un nouveau secret pour stocker nos identifiants Git.
3. Une fois le repository stage en place dans Snowflake, nous le synchronisons avec le dépôt distant pour importer le code dans Snowflake.
4. Enfin, nous créons une procédure stockée dans Snowflake et importons le code handler depuis notre repository stage.

Passons en revue chaque étape en détail.

1. Développement du code handler

J'ai créé une fonction handler toute simple appelée hello_world et l'ai poussée dans mon dépôt. Nous pouvons maintenant créer les objets nécessaires dans Snowflake et relier ce dépôt distant à un nouveau repository stage dans Snowflake.

2. Création du secret

Commençons par la création du secret. J'utilise un personal access token pour l'authentification.

3. Création de l'API integration

Il nous faut également une nouvelle API integration pour relier Snowflake à GitHub. Le paramètre API_ALLOWED_PREFIXES pointe vers l'URL de mon compte GitHub, et l'authentification s'appuie sur le secret créé à l'étape précédente.

4. Création du repository stage

Nous pouvons enfin créer un repository stage Git en y passant les valeurs créées précédemment. L'origine correspond au dépôt Git auquel nous souhaitons nous connecter.

5. Synchronisation du repository stage avec le dépôt distant

Le repository stage est en place ; synchronisons-le avec le dépôt distant.

6. Création de la procédure stockée

Et voilà ! L'intégration entre Snowflake et le dépôt Git distant est désormais opérationnelle. Le handler de notre procédure stockée provient du repository stage, lui-même synchronisé avec le dépôt distant. Créons la procédure stockée :

7. Synchronisation avec le dépôt distant

Comment l'exécuter ?

Modifions à présent le code pour voir à quel point il est simple de récupérer les mises à jour dans Snowflake. Là encore, ces modifications se font localement dans VS Code, puis sont poussées vers le dépôt distant. Apportons un changement simple : mettre le message en majuscules.

Une fois les modifications poussées dans le dépôt, il nous faut mettre à jour (synchroniser) notre repository stage dans Snowflake.

1ALTER GIT REPOSITORY snowflake_git_demo FETCH;

Le code handler mis à jour est désormais disponible dans Snowflake ! C'est tout — rien de plus à faire. Pas besoin de recréer la procédure, ni quoi que ce soit. Il suffit d'exécuter la procédure stockée pour vérifier que le code a bien été mis à jour :

8. Mise à jour automatique à chaque merge

Il existe un moyen d'automatiser tout cela. Supposons que vous suiviez un workflow Git classique, en conservant vos modifications dans des feature branches dédiées qui doivent être fusionnées dans la branche main. Nous pouvons construire un workflow GitHub Actions qui exécute la commande ALTER GIT REPOSITORY à chaque merge de PR : le repository stage est alors automatiquement mis à jour dès qu'un nouveau code arrive dans votre branche main !

Voici un exemple simple. Vous pouvez utiliser SnowSQL ou SnowCLI pour exécuter l'instruction SQL.

TORY command when the PR is merged, so the repository stage is automatically updated every time you push new code into your main branch!

Here is a simple example. You can use either SnowSQL or SnowCLI to run the SQL statement.

name: Deploying Stored procedure updates
env:
  SNOWSQL_ACCOUNT: ${{secrets.SF_ACCOUNT}}
  SNOWSQL_USER: ${{secrets.SF_USER}}
  SNOWSQL_PWD: ${{secrets.SF_PASSWORD}}
  SNOWSQL_DATABASE: ${{ secrets.SF_DATABASE }}
  SNOWSQL_SCHEMA: ${{ secrets.SF_SCHEMA }}
  SNOWSQL_ROLE: ${{ secrets.SF_ROLE }}
  SNOWSQL_WAREHOUSE: ${{ secrets.SF_WAREHOUSE }}

on:

Afficher le code

Et voici le résultat de l'exécution du workflow GitHub Actions :

Maintenant que la mise en place de l'intégration Git est claire, d'autres fonctionnalités méritent d'être explorées :

Gérer les dépôts dans Snowflake

Notre exemple n'a montré que deux opérations liées aux dépôts Git dans Snowflake : la création du repository stage et la commande ALTER pour récupérer les mises à jour distantes. Voici d'autres opérations que vous pourriez vouloir effectuer sur vos dépôts :

Lister les branches d'un dépôt

Nous pouvons lister toutes les branches de notre repository stage, avec le chemin et le hash de commit.

1SHOW GIT BRANCHES IN snowflake_git_demo;

Lister les fichiers du dépôt

Comme pour n'importe quel stage interne ou externe, on peut lister les fichiers du repository stage avec la commande LIST :

1LS @snowflake_git_demo

Repository stage

Mais dans le cas du repository stage, on peut aussi lister les fichiers par nom de branche :

1LS @snowflake_git_demo/branches/main

Hash d'un commit individuel

1LS @snowflake_git_demo/commits/<<add_my_commit_hash>>

Lister les fichiers par nom de tag

1LS @snowflake_git_demo/tags/tag_name

Vérifier les propriétés du repository stage

Comme pour bien d'autres objets Snowflake, des commandes SHOW et DESCRIBE existent pour les repository stages. Elles affichent des métadonnées utiles : l'emplacement de votre repository stage (nom de la base et du schéma), l'origine du dépôt distant, l'API integration utilisée pour relier Git et Snowflake, ainsi que le nom du secret qui contient les identifiants de connexion au dépôt Git distant.

Exécuter le code depuis un dépôt

Conserver des fichiers dans un dépôt, c'est utile, mais qu'en est-il de l'exécution du code qu'ils contiennent ? Y avez-vous pensé ? Snowflake propose la commande EXECUTE IMMEDIATE FROM, qui permet d'exécuter du code SQL directement depuis un fichier. Vous pouvez par exemple stocker la configuration de votre compte (utilisateurs, rôles, création d'entrepôts) dans des fichiers SQL au sein du dépôt, puis les exécuter directement grâce à cette commande :

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

Copier du code d'un dépôt dans une worksheet

Vous pouvez également copier le code des fichiers stockés dans le repository stage vers vos worksheets. La copie fonctionne aussi bien pour les fichiers .sql que .py. Vous pouvez ensuite éditer ou exécuter ce code dans les worksheets Snowsight. Il suffit de naviguer jusqu'au fichier à copier et de choisir l'option Copy into worksheet.

Pour enregistrer vos modifications dans le dépôt, il faut passer par votre copie locale : les dépôts sont pour l'instant en lecture seule dans Snowflake, à l'exception des Notebooks, qui peuvent écrire en retour. Seuls les Notebooks permettent donc d'écrire dans les dépôts. Voici les autres limitations actuelles de la fonctionnalité :

• Lecture seule — voir ci-dessus.
• Accès via Internet public uniquement. Impossible d'atteindre des dépôts situés derrière un réseau privé.
• Le repository stage ne peut pas être partagé via le data sharing.
• Impossible de créer un repository stage à l'intérieur d'un application package.
• Impossible de créer un repository stage à l'intérieur d'une native app côté client.
• L'accès aux fichiers du repository stage peut être plus lent qu'à ceux d'un stage interne Snowflake. À éviter pour les cas d'ingestion de données.
• Les submodules ne sont pas pris en charge pour le moment.

L'exemple complet a illustré l'un des cas d'usage possibles de l'intégration Git dans Snowflake : versionner le code de vos procédures et UDF dans un dépôt distant. Mais ce n'est pas le seul.

L'intégration Git est aussi essentielle pour piloter votre compte selon les pratiques DevOps. Vous pouvez conserver les définitions de vos objets Snowflake (bases, entrepôts, utilisateurs, rôles, etc.) dans un dépôt distant sous forme de fichiers SQL contenant des instructions CREATE ou ALTER, puis les exécuter dans le cadre de vos pipelines CI/CD. Grâce aux repository stages, vous disposez d'une copie de ces définitions directement dans Snowflake et pouvez y exécuter le code sur place, sans runner externe pour déployer ces objets !

Autre cas d'usage : vos native apps et applications Streamlit, dont le code peut être nativement relié à des dépôts distants. Enfin, si vous utilisez Snowflake pour vos transformations de données — DAGs de tasks ou tables dynamiques — vous pouvez versionner les définitions de pipelines et les intégrer facilement aux repository stages et à l'environnement Snowflake.

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. Fort de plus d'une décennie d'expérience dans la data, il a occupé les rôles de Snowflake data engineer, architecte et administrateur sur des projets variés, dans de nombreux secteurs et environnements technologiques. Membre actif de la communauté, il partage généreusement son expertise et inspire ses pairs. Il est également formateur O'Reilly et anime des sessions de formation en ligne en direct.