Intégration de CI/CD à Snowflake CLI¶

Snowflake CLI s’intègre aux plateformes CI/CD populaires (intégration continue et livraison continue) afin que vous puissiez automatiser les déploiements Snowflake pour les projets DCM, applications Snowpark, Snowflake Native Apps et scripts SQL autonomes. Snowflake publie et tient à jour les intégrations de premier niveau pour les systèmes CI/CD les plus utilisées ; pour toute plateforme pouvant exécuter une commande shell, vous pouvez également installer Snowflake CLI directement.

Pour des concepts DevOps plus larges, y compris la gestion déclarative des objets et la stratégie d’environnement, voir DevOps avec Snowflake.

Intégrations CI/CD prises en charge¶

Snowflake gère les intégrations CI/CD de premier niveau suivantes. Chaque intégration installe Snowflake CLI sur l’exécuteur et configure l’authentification vers Snowflake.


Intégration	Statut	Authentification (recommandée)	Référence
Action GitHub	Aperçu public	Fédération d’identité de charge de travail (OIDC)	GitHub Action Snowflake CLI

Note

Si vous utilisez des Jenkins, Bitbucket Pipelines, CircleCI ou un autre système CI qui n’est pas répertorié dans la table précédente, vous pouvez installer Snowflake CLI avec une seule commande shell dans votre pipeline. Voir Installation de Snowflake CLI sur d’autres systèmes CI.

Configuration commune côté Snowflake¶

Tous les intégrations CI/CD de premier niveau suivent le même schéma du côté de Snowflake :

Créer un utilisateur de service avec lequel le pipeline s’authentifie.
Configurez la méthode d’authentification de l’utilisateur de service. Snowflake recommande la fédération d’identité de charge de travail (WIF) avec OpenID Connect (OIDC ) de sorte qu’aucun secret à longue durée de vie ne soit stocké dans le système CI.
Accordez à l’utilisateur du service les rôles dont il a besoin pour déployer vos objets.

S’authentifier avec la fédération d’identité de charge de travail (OIDC)¶

Avec OIDC, l’exécuteur CI obtient un jeton d’identité de courte durée que Snowflake valide directement. Chaque plateforme CI publie des jetons d’un émetteur différent avec un format de revendication d’objet différent ; les pages de référence d’intégration documentent les valeurs exactes à utiliser.

Une définition minimale de l’utilisateur de service ressemble à ce qui suit. Remplacez les valeurs ISSUER et SUBJECT par celles requises par votre plateforme CI (voir la page de référence d’intégration correspondante).

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

Pour l’arrière-plan sur SnowflakeWIF, voir Fédération d’identité de charge de travail.

S’authentifier avec une paire de clés ou un mot de passe¶

LorsqueOIDC n’est pas disponible (par exemple, lorsque vous devez prendre en charge les anciennes versions de Snowflake CLI ou les exécuteurs CI on-premise), utilisez l’authentification par paire de clés. Stockez la clé privée en tant que secret CI et transmettez-la dans l’environnement en utilisant SNOWFLAKE_PRIVATE_KEY_RAW (pour une connexion temporaire) ou SNOWFLAKE_CONNECTIONS _<NAME> _PRIVATE_KEY_RAW (pour une connexion nommée).

L’authentification par mot de passe est prise en charge pour les workflows hérités, mais n’est pas recommandée pour la production.CI/CD. Voir Gestion des connexions Snowflake pour la liste complète des paramètres d’authentification.

Fichiers de configuration et variables d’environnement¶

La plupart des workflows CI/CD combinent un fichier config.toml versionné avec des secrets injectés via des variables d’environnement. Les règles de priorité suivantes s’appliquent :

Les paramètres de ligne de commande remplacent tout.
Les variables d’environnement qui ciblent un paramètre de connexion spécifique (par exemple, SNOWFLAKE_CONNECTIONS_MYCONNECTION_PASSWORD) remplacent config.toml.
Les valeurs définies dans config.toml sont utilisés lorsqu’aucun remplacement n’est fourni.
Les variables d’environnement génériques, telles que SNOWFLAKE_USER s’appliquent en dernier.

Pour plus de détails, y compris une référence de paramètre complète, voir Gestion des connexions Snowflake.

Installation de Snowflake CLI sur d’autres systèmes CI¶

Vous pouvez exécuter Snowflake CLI sur n’importe quel exécuteur CI qui peut exécuter une commande shell. L’installation canonique à une seule ligne utilise uv :

uv tool install snowflake-cli
snow --version

Pour des options d’installation sur des systèmes d’exploitation spécifiques, voir Installation de Snowflake CLI. Pour la gestion des connexions (y compris l’utilisation de variables d’environnement pour éviter de stocker des identifiants de connexion sur le exécuteur), voir Gestion des connexions Snowflake.

Tâches de pipeline typiques¶

La table suivante mappe les tâches de pipeline CI/CD communes vers les commandes Snowflake CLI qui les mettent en œuvre. Les mêmes commandes fonctionnent à partir de n’importe quel système CI.


Tâche de pipeline	Commande Snowflake CLI	Description
Prévisualisation des modifications de la demande d’extraction	:codenowrap :`snow dcm plan`	Calcule un plan de création, de modification et de suppression par rapport à l’environnement cible. Publier la sortie en tant que commentaire PR pour vérification.
Déployer sur la fusion	`snow dcm deploy`	Applique un ensemble de modifications précédemment planifiées à l’environnement cible.
Exécuter Snowpark ou des scripts SQL	`snow sql -f <file>`, `snow snowpark deploy`	Exécute des déploiements scriptés pour les objets non encore couverts par DCM.
Configurez un objet de référentiel Git	`snow git execute`	Exécute les fichiers SQL directement à partir d’une intégration Git de Snowflake.

Recommandations de sécurité¶

Utilisez la fédération d’identité de charge de travail (OIDC) où votre système CI la prend en charge. Évitez de stocker des identifiants de connexion à longue durée de vie dans les secrets CI.
Créez un utilisateur de service dédié pour chaque environnement de pipeline (par exemple, un utilisateur par référentiel ou par environnement). Accordez uniquement les rôles requis pour ce pipeline.
Utilisez Contrôle du trafic réseau avec des politiques réseau pour restreindre quelles IPs source peuvent s’authentifier en tant qu’utilisateur du service lorsque cela est possible.
Ne validez pas les fichiers config.toml qui contiennent des identifiants de connexion. Ne validez que le squelette de connexion et fournissez des secrets à travers des variables d’environnement.
Faites pivoter les clés privées et les mots de passe régulièrement si vous ne pouvez pas les adopter OIDC.