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.

  Un exemple de workflow CI/CD permettant de planifier un DCM project à partir d’un clone de référentiel Git local :

  CopyExpand

  steps:
    - name: Clone Repo
      uses: actions/checkout@v4
    - name: Setup SnowCLI
      uses: snowflakedb/snowflake-cli-action@v2.0
    - name: Run PLAN
      run: |
        cd ./Quickstarts/DCM_Project_Quickstart_1/
        snow dcm plan --target PROD --save-output
  

  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 procédure ou une tâche 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¶

La sortie du plan standard contient les informations suivantes sur l’exécution du plan au format JSON :

version: 2
metadata:
  timestamp: <timestamp>
  query_id: <query_id>
  project_name: <project_name>
  user: <user>
  role_name: <role_name>
  command: <command>
  changes:
    - kind: <kind>
        "attribute_name": <attribute_name>,
        "value": <value>
        "changes": [
          {
            "kind": <kind>,
            "attribute_name": <attribute_name>,
            "value": <value>
          }
        ]
      }
    ]
  }
}

Exemple de sortie de plan :

{
  "version": 2,
  "metadata": {
    "timestamp": <timestamp>,
    "query_id": <query_id>,
    "project_name": <project_name>,
    "user": <user>,
    "role_name": <role_name>,
    "command": <command>
  },
  "changeset": [
    {
      "type": "CREATE",
      "object_id": {
        "domain": "TABLE",
        "name": "CUSTOMER_SUMMARY",
        "fqn": "MY_DB.ANALYTICS.CUSTOMER_SUMMARY",
        "database": "MY_DB",
        "schema": "ANALYTICS"
      },
      "changes": [
        {
          "kind": "set",
          "attribute_name": "warehouse_size",
          "value": "XSMALL"
        },
        {
          "kind": "set",
          "attribute_name": "query",
          "value": "SELECT customer_id, SUM(amount) AS total FROM orders GROUP BY customer_id"
        }
      ]
    },
    {
      "type": "ALTER",
      "object_id": {
        "domain": "DYNAMIC_TABLE",
        "name": "ORDER_DETAILS",
        "fqn": "MY_DB.ANALYTICS.ORDER_DETAILS",
        "database": "MY_DB",
        "schema": "ANALYTICS"
      },
      "changes": [
        {
          "kind": "changed",
          "attribute_name": "warehouse_size",
          "value": "SMALL",
          "prev_value": "XSMALL"
        },
        {
          "kind": "collection",
          "collection_name": "columns",
          "id_label": "name",
          "changes": [
            {
              "kind": "added",
              "item_id": "DISCOUNT_AMOUNT",
              "changes": [
                {
                  "kind": "set",
                  "attribute_name": "data_type",
                  "value": "NUMBER(10,2)"
                }
              ]
            },
            {
              "kind": "modified",
              "item_id": "ORDER_STATUS",
              "changes": [
                {
                  "kind": "changed",
                  "attribute_name": "data_type",
                  "value": "VARCHAR(50)",
                  "prev_value": "VARCHAR(20)"
                }
              ]
            },
            {
              "kind": "removed",
              "item_id": "LEGACY_FLAG"
            }
          ]
        }
      ]
    },
    {
      "type": "DROP",
      "object_id": {
        "domain": "VIEW",
        "name": "OLD_REPORT_VIEW",
        "fqn": "MY_DB.ANALYTICS.OLD_REPORT_VIEW",
        "database": "MY_DB",
        "schema": "ANALYTICS"
      },
      "changes": []
    }
  ]
}

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 \
--configuration DEV \
--variable "wh_size='MEDIUM'" --variable "teams = ['TEAM_A', 'TEAM_B']" \
--alias 'testing 2 teams'

Consultez Sortie du plan 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.

Exemples GitHub Actions¶

Cette section fournit des exemples de workflows GitHub Actions illustrant des modèles CI/CD typiques pour DCM Projects. Les mêmes concepts s’appliquent à d’autres plateformes basées sur Git, comme Azure DevOps, GitLab CI/CD ou Bitbucket Pipelines. Seule la syntaxe du workflow diffère.

Chaque exemple fournit des éléments de base que vous pouvez personnaliser et combiner en fonction de la configuration de votre pipeline, de la topologie de votre environnement et des exigences organisationnelles.

Les exemples de workflows illustrent les modèles suivants, applicables à toute configuration DCM CI/CD :

• Configuration pilotée par manifeste Chaque workflow lit account_identifier, project_owner et``project_name`` à partir des cibles du manifeste. Ceci conserve la configuration de l’environnement à un seul endroit et évite de la dupliquer à travers les secrets GitHub.

• Protection contre la suppression des données Le workflow de déploiement analyse plan_result.json pour les opérations DROP destructrices sur les objets contenant des données, tels que les bases de données, les schémas, les tables et les zones de préparation, et bloque le déploiement s’il en détecte.

• Promotion séquentielle de la zone de préparation vers la production Le déploiement en production ne commence qu’une fois que le déploiement de la zone de préparation a abouti, que les tables dynamiques ont été actualisées et que les tests de qualité des données ont été validés.

• Analyse de la sortie du plan structuré Les workflows utilisent jq pour extraire les nombres d’opérations et les domaines d’objets de plan_result.json, ce qui facilite la création de résumés et de contrôles personnalisés.

• Résumés alimentés par AI snow cortex complete génère des résumés en langage naturel des résultats du script post-hook et de la sortie de l’actualisation de la table dynamique pour le résumé de la tâche GitHub Actions.

Avant d’exécuter ces exemples de workflows, remplissez les conditions préalables suivantes :

• Stocker les fichiers DCM project dans un référentiel Git.

• Accorder à un utilisateur des privilèges pour créer et exécuter GitHub Actions.

• Configurer les secrets GitHub pour les identifiants de connexion de l’utilisateur du service Snowflake (SNOWFLAKE_USER, SNOWFLAKE_PASSWORD ou un jeton d’accès personnel).

• Configurer les variables GitHub pour le chemin vers le dossier DCM project (DCM_PROJECT_PATH).

• Configurer les environnements GitHub pour chaque cible de manifeste (par exemple, DCM_STAGE, DCM_PROD_US).

Pour la configuration d’une connexion Snowflake dans GitHub Actions, consultez la première moitié de l’article de blog, Guide pratique sur GitHub Actions CI/CD.

Consultez le référentiel DCM snowflake-labs pour un ensemble de workflows GitHub Actions qui couvrent la totalité du cycle de vie CI/CD pour DCM Projects.

Tous les exemples de workflows lisent le rôle account_identifier et project_owner Snowflake directement à partir des cibles du manifeste à l’aide de yq, de sorte que la configuration spécifique à l’environnement existe dans le manifest.yml contrôlé par la version plutôt que dans des secrets GitHub dupliqués. Seules les identifiants de connexion de l’utilisateur du service sont stockés en tant que secrets.