Déployer et gérer DCM Projects¶

Outils d’interface¶

Vous disposez des options d’interface suivantes pour DCM Projects.

Intégration Git¶

Connectez-vous au référentiel Git dans lequel vos fichiers de définition DCM project sont stockés.

Rôles et privilèges requis¶

Le rôle de l’utilisateur qui crée un objet DCM project doit disposer des rôles et privilèges suivants :

• Le privilège CREATE DCM PROJECT ON SCHEMA :

  CopyExpand

  GRANT CREATE DCM PROJECT ON SCHEMA <schema_name> TO ROLE <role_name>;
  

  Show lessSee more

  Scroll to top

Créer une DCM project¶

Créez un objet DCM project à l’aide de l’une des options suivantes.

CREATE [OR REPLACE] DCM PROJECT [IF NOT EXISTS] <my_project>
[COMMENT = 'my comment'];

snow dcm create <my_project> --if-not-exists

snow dcm create <my_project> --if-not-exists

snow dcm create # uses the name specified in the default target from the manifest

snow dcm create --target # uses the named target from the manifest

Propriété sur les objets gérés par DCM¶

Le rôle qui déploie un DCM project, dispose, par défaut, du privilège OWNERSHIP associé à tous les objets déployés.

Les définitions de projets peuvent inclure les instructions GRANT OWNERSHIP vers d’autres rôles. Snowflake recommande que le rôle de propriétaire DCM project n’accorde la propriété des objets gérés par DCM qu’à un autre rôle de niveau inférieur dont il dispose également. Le projet peut alors continuer à gérer cet objet, car le rôle de propriétaire du projet « hérite » des privilèges du nouveau rôle de propriétaire de l’objet.

Si le rôle de propriétaire DCM project accorde la propriété sur les objets gérés par DCM à un autre rôle dont il ne dispose pas, le projet ne peut plus gérer cet objet déployé, car le rôle de propriétaire du projet n’en est plus propriétaire. Les déploiements suivants échoueront. La définition de l’objet doit être supprimée du projet ou la propriété doit être restituée au rôle de propriétaire du projet.

Si vous souhaitez migrer des objets existants pour qu’ils soient gérés par un DCM project, le rôle propriétaire de l’objet DCM project doit également disposer de privilèges de propriété (directs ou hérités par d’autres rôles) sur l’objet à gérer par DCM project.

Exécutez la commande PLAN¶

La commande PLAN prend les informations suivantes en entrée :

• Chemin d’accès au fichier manifeste

  La CLI lit la cible du manifeste (indicateur default_target ou --target). Pour les commandes SQL, le chemin d’accès au fichier manifeste et le nom du projet doivent être indiqués.

• Valeurs définies pour les variables Jinja (facultatif).

• La templating_config de la cible sélectionne automatiquement le profil de configuration. Pour les commandes SQL, utilisez la clause USING CONFIGURATION pour spécifier le profil.

• Une ou plusieurs valeurs du profil de configuration à remplacer (facultatif).

Les exemples suivants montrent comment exécuter la commande PLAN.

Snowflake CLISnowsightSQL

Exécutez la commande snow dcm plan dans votre terminal IDE local ou dans le cadre d’un workflow Git.

Un exemple de commande CLI permettant de planifier un projet DCM à partir d’un répertoire local :

CopyExpand

cd ./Quickstarts/DCM_Project_Quickstart_1/
snow dcm plan

Show lessSee more

Scroll to top

Un exemple de commande CLI permettant de planifier un projet DCM à partir d’une zone de préparation Snowflake ou d’un clone de référentiel Git :

CopyExpand

snow dcm plan --target PROD_US --save-output

Show lessSee more

Scroll to top

Un exemple de commande CLI permettant de planifier un projet DCM avec des arguments facultatifs :

CopyExpand

snow dcm plan
--variable "wh_size='MEDIUM'" --variable "teams = ['TEAM_A', 'TEAM_B']"
--save-output

Show lessSee more

Scroll to top

Les variables doivent être placées entre guillemets doubles, avec des guillemets simples supplémentaires pour les valeurs de type chaîne. Les listes de valeurs doivent être placées entre crochets.

Chemin du fichier de définition¶

Vous disposez des options suivantes pour indiquer l’emplacement des fichiers de manifeste et de définition.

• À partir d’un chemin d’accès à l’espace de travail

  L’interface utilisateur de Snowsight liste automatiquement toutes les définitions DCM project dans l’espace de travail actuel. Vous pouvez sélectionner l’un de ces chemins et les espaces de travail l’utiliseront pour exécuter des commandes DCM.

  Si vous voulez exécuter manuellement des commandes SQL dans les espaces de travail, vous pouvez également indiquer ce même chemin dans l’un de vos espaces de travail.

  Conseil : le menu à trois points situé derrière chaque fichier de votre espace de travail vous permet de copier le chemin d’accès complet de ce fichier dans votre code SQL.

  Un exemple de commande SQL permettant de planifier un projet DCM à partir d’un chemin d’espace de travail :

  CopyExpand

  EXECUTE DCM PROJECT DCM_PROJECT_DEV
    PLAN
    USING CONFIGURATION DEV
  FROM
    'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/Quickstarts/DCM_Project_Quickstart_1'
  

  Show lessSee more

  Scroll to top

• À partir d’un clone de référentiel Git local sur votre disque

  Sélectionnez le répertoire qui contient voter fichier manifest.yml avant d’exécuter la commande CLI dans votre IDE local. Vous pouvez également spécifier un autre répertoire local contenant le manifeste et les définitions que vous souhaitez utiliser.

  Un exemple de commande CLI permettant de planifier un DCM project à partir du répertoire actuel d’un référentiel Git local :

  CopyExpand

  cd ./Quickstarts/DCM_Project_Quickstart_1/
  
  snow dcm plan
  
  snow dcm plan --target PROD
  

  Show lessSee more

  Scroll to top

  Un exemple de commande CLI permettant de planifier un DCM project à partir d’un répertoire différent dans un clone de référentiel Git local :

  CopyExpand

  snow dcm plan DCM_PROJECT_DEV --configuration DEV --from ./Quickstarts/DCM_Project_Quickstart_2/
  

  Show lessSee more

  Scroll to top

• Depuis votre référentiel distant dans un workflow

  La même syntaxe CLI peut être utilisée lorsque les commandes DCM sont exécutées dans un workflow CI/CD. Vous pouvez appeler le CLI directement ou utiliser les actions GitHub réutilisables du référentiel DCM snowflake-labs, qui traitent la configuration CLI, l’authentification et les commandes DCM en interne.

  Exemple d’utilisation de l’action dcm-plan réutilisable :

  CopyExpand

  steps:
    - uses: actions/checkout@v4
    - uses: Snowflake-Labs/snowflake-dcm-projects/actions/dcm-plan@v1
      with:
        target: PROD
        project-path: Quickstarts/DCM_Project_Quickstart_1/
        snowflake-user: ${{ env.SNOWFLAKE_USER }}
  

  Show lessSee more

  Scroll to top

• À partir d’un clone de référentiel Stage ou Git dans Snowflake

  Si vous souhaitez exécuter une PROCEDURE ou une TASK dans Snowflake qui exécute des commandes DCM, cette commande SQL peut indiquer un chemin absolu vers une zone de préparation Snowflake ou un clone de référentiel Git au sein du compte.

  Pour les clones du référentiel Git, envisagez d’abord d’exécuter ALTER GIT REPOSITORY FETCH pour disposer de la dernière version.

  Les chemins '@...' ne peuvent être utilisés que lors de l’exécution de commandes DCM SQL.

  Un exemple de commande SQL permettant de planifier un projet DCM à partir d’une zone de préparation ou d’un clone de référentiel Git dans Snowflake :

  CopyExpand

  EXECUTE DCM PROJECT DCM_PROJECT_DEV
    PLAN
    USING CONFIGURATION DEV
  FROM
    '@DCM_DEMO.DEPLOY.DCM_DEMO/branches/main/Quickstarts/DCM_Project_Quickstart_1/'
  

  Show lessSee more

  Scroll to top

Sortie du plan¶

Pour le format de sortie PLAN et DEPLOY, y compris le schéma JSON et des exemples, consultez la section dédiée à la sortie PLAN et DEPLOY de la référence de la commande EXECUTE DCM PROJECT.

Exécutez la commande DEPLOY¶

Pour exécuter la commande DEPLOY, fournissez les entrées suivantes :

• Chemin d’accès au fichier manifeste.

• Un profil de configuration doit être nommé si les profils de configuration sont définis dans le manifeste.

• De manière facultative, les valeurs du profil de configuration qui remplacent les valeurs par défaut.

• De manière facultative, un alias de déploiement.

Les exemples suivants montrent comment exécuter la commande DEPLOY.

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV
  DEPLOY
FROM
  'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/Quickstarts/DCM_Project_Quickstart_1';

EXECUTE DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV
  DEPLOY AS "testing 2 teams"
  USING CONFIGURATION DEV (wh_size => 'MEDIUM', teams => ['TEAM_A', 'TEAM_B'])
FROM
  'snow://workspace/USER$.PUBLIC.DEFAULT$/versions/live/Quickstarts/DCM_Project_Quickstart_1';

cd ./Quickstarts/DCM_Project_Quickstart_1/
snow dcm deploy DCM_DEMO.PROJECTS.DCM_PROJECT_DEV

snow dcm deploy --target PROD_US

snow dcm deploy DCM_DEMO.PROJECTS.DCM_PROJECT_DEV \
--target DCM_DEV \
--variable "wh_size='MEDIUM'" --variable "teams = ['TEAM_A', 'TEAM_B']" \
--alias 'testing 2 teams'

Consultez Sortie PLAN et DEPLOY pour la structure de sortie du plan standard.

Afficher tous les objets gérés par un DCM project¶

La commande SHOW ENTITIES IN DCM PROJECT vous permet de voir une liste de tous les objets Snowflake qui sont actuellement gérés par un DCM project spécifique. Elle fournit une liste de noms complets pour tous les objets. Pour voir les résultats, vous devez disposer du privilège READ sur l’DCM project et des privilèges pour voir l’objet géré lui-même.

Vous pouvez utiliser LIKE pour effectuer une recherche par nom ou utiliser un opérateur de flux pour poursuivre le traitement ou filtrer le jeu de résultats.

De même, vous pouvez SHOW GRANTS et SHOW FUTURE GRANTS qui sont définis et déployés avec ce projet.

Exemples pour voir tous les objets qui sont actuellement gérés par un DCM project :

SHOW ENTITIES LIKE '%DASHBOARD%' IN DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV;

SHOW ENTITIES IN DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV
  ->> SELECT * FROM $1 WHERE "object_type" = 'DYNAMIC_TABLE';

SHOW [FUTURE] GRANTS IN DCM PROJECT DCM_DEMO.PROJECTS.DCM_PROJECT_DEV;

Détacher des objets d’un DCM project¶

À l’aide de la commande ALTER <objet> avec la clause UNSET DCM PROJECT, vous pouvez détacher un objet qui a été déployé et qui est maintenant géré par un DCM project. La commande supprime l’association entre l’objet et l’DCM project sans supprimer l’objet. Vous pouvez utiliser cette commande lorsque vous souhaitez commencer à gérer un objet via un DCM project différent.

Assurez-vous de supprimer l’instruction DEFINE correspondante de vos fichiers de définition de projet avant de le déployer à nouveau. Dans le cas contraire, l’objet sera réintégré dans le DCM project.

Un exemple de commande SQL pour détacher un objet d’un DCM project :

ALTER TABLE MY_DB.MY_SCH.MY_TABLE
  UNSET DCM PROJECT;

Vous ne pouvez pas détacher des autorisations ou des exécutions déployées d’un projet DCM.

Supprimer un DCM project¶

Lorsqu’un objet DCM project est supprimé, l’ensemble des entités gérées, des autorisations et des attentes restent en place comme « non gérés ».

DROP DCM PROJECT [IF EXISTS] <my_project>;

snow dcm drop my_project

Bonnes pratiques CI/CD¶

Suivez ces pratiques lorsque vous automatisez des déploiements à l’aide de pipelines CI/CD :

• Un DCM project ciblant un environnement de non-production doit appartenir à un rôle différent de son homologue de production afin d’éviter des déploiements accidentels vers la production.

• Un DCM project ciblant un environnement de production doit appartenir à un rôle dédié aux déploiements de production avec des privilèges d’accès spécifiquement adaptés qui sont juste suffisants pour déployer tous les objets du projet.

  • Évitez d’utiliser les rôles d’administrateur général pour la propriété DCM project. Accordez de tels rôles uniquement aux utilisateurs des services, et non aux développeurs individuels.

  • Accordez le rôle de déploiement de production dédié uniquement aux utilisateurs du service, et non aux développeurs individuels.

  • Limitez la propriété au rôle de déploiement de production pour garantir l’immuabilité de l’infrastructure ou des produits de données critiques.

    Si le rôle de déploiement de production dédié accorde la propriété des objets de production à d’autres rôles, les utilisateurs qui se voient attribuer ces rôles peuvent toujours modifier ou supprimer les objets de production.

Actions GitHub¶

Le référentiel labos-snowflakeDCM _ fournit un ensemble d’actions GitHub composites réutilisables qui automatisent les pipelines DCM Projects. Chaque action traite une étape du cycle de vie, et vous pouvez les référencer à partir de vos propres workflows pour créer des pipelines CI/CD de bout en bout. Seule la syntaxe du workflow diffère selon les plateformes ; les mêmes concepts CI/CD s’appliquent aux pipelines Azure DevOps, GitLab CI/CD, Bitbucket et autres.

Les actions réutilisables suivantes sont disponibles :

Pour utiliser une action dans votre flux de travail, faites-y référence avec :

- uses: Snowflake-Labs/snowflake-dcm-projects/actions/<action-name>@v1

Pour une documentation complète des entrées et sorties de chaque action, voir les `actions README<https://github.com/Snowflake-Labs/snowflake-dcm-projects/blob/main/actions/README.md>`__.

CREATE USER SVC_GITHUB_ACTIONS
  TYPE = SERVICE
  DEFAULT_ROLE = 'PUBLIC'
  COMMENT = 'GitHub Actions service user for CI/CD via OIDC'
  WORKLOAD_IDENTITY = (
    TYPE = OIDC
    ISSUER = 'https://token.actions.githubusercontent.com'
    SUBJECT = 'repo:<owner>/<repo>:environment:<env_name>'
  );