Bereitstellen und Verwalten von DCM Projects¶

Benutzeroberflächen-Tools¶

Sie haben die folgenden Optionen für die Weboberfläche von DCM Projects.

Git-Integration¶

Stellen Sie eine Verbindung zum Git-Repository her, in dem Ihre DCM project-Definitionsdateien gespeichert sind.

Erforderliche Rollen und Berechtigungen¶

Die Rolle des Benutzers, der ein DCM project-Objekt erstellt, muss die folgenden Rollen und Berechtigungen haben:

• CREATE DCM PROJECT ON SCHEMA-Berechtigung:

  CopyExpand

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

  Show lessSee more

  Scroll to top

Erstellen Sie eine DCM project, wenn:¶

Erstellen Sie ein DCM project-Objekt mithilfe einer der folgenden Optionen:

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

Eigentümerschaft an DCM-verwalteten Objekten¶

Die Rolle, mit der ein DCM project bereitgestellt wird, hat standardmäßig die OWNERSHIP-Berechtigung für alle bereitgestellten Objekte.

Die Projektdefinitionen können GRANT OWNERSHIP-Anweisungen für andere Rollen enthalten. Snowflake empfiehlt, dass die DCM project-Eigentümerrolle die Eigentümerschaft für DCM-verwaltete Objekte nur an eine andere untergeordnete Rolle, die sie ebenfalls innehat, gewährt. Dann kann das Projekt dieses Objekt weiterhin verwalten, da die Projekteigentümerrolle die Berechtigungen der neuen Objekteigentümerrolle „erbt“.

Wenn die DCM project-Eigentümerrolle die Eigentümerschaft für DCM-verwaltete Objekte auf eine andere Rolle überträgt, die es nicht selbst besitzt, kann das Projekt dieses bereitgestellte Objekt nicht mehr verwalten, da die Eigentümerrolle des Projekts nicht mehr die Eigentümerschaft hat. Nachfolgende Bereitstellungen werden fehlschlagen. Die Objektdefinition muss aus dem Projekt entfernt werden oder die Eigentümerschaft muss wieder an die Rolle des Projektbesitzers zurückgegeben werden.

Wenn Sie vorhandene Objekte migrieren möchten, damit sie von einem DCM project verwaltet werden sollen, muss die Eigentümerrolle des DCM project-Objekts außerdem über Eigentümerrechte (direkt oder geerbt durch andere Rollen) für das Objekt verfügen, das vom DCM project verwaltet werden soll.

Führen Sie den Befehl PLAN aus¶

Der Befehl PLAN benötigt die folgenden Informationen als Eingabe:

• Der Pfad zur Manifest-Datei

  Die CLI liest das Ziel aus dem Manifest (default_target oder --target-Flag). Für SQL-Befehle müssen der Pfad zur Manifest-Datei und der Projektname angegeben werden.

• Definierte Werte für Jinja-Variablen (optional).

• templating_config des Ziels wählt automatisch das Konfigurationsprofil aus. Für SQL-Befehle verwenden Sie die USING CONFIGURATION-Klausel, um das Profil anzugeben.

• Ein oder mehrere Werte des Konfigurationsprofils, die überschrieben werden sollen (optional).

Im Folgenden finden Sie Beispiele für die Ausführung des PLAN-Befehls.

Snowflake CLISnowsightSQL

Führen Sie den Befehl snow dcm plan in Ihrem lokalen IDE-Terminal oder als Teil eines Git-Workflows aus.

Beispiel für einen CLI-Befehl, um ein DCM-Projekt aus einem lokalen Verzeichnis zu planen:

CopyExpand

cd ./Quickstarts/DCM_Project_Quickstart_1/
snow dcm plan

Show lessSee more

Scroll to top

Beispiel für einen CLI-Befehl, um ein DCM-Projekt aus einem Snowflake-Stagingbereich oder Git-Repository-Klon zu planen:

CopyExpand

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

Show lessSee more

Scroll to top

Beispiel für einen CLI-Befehl, um ein DCM-Projekt mit optionalen Argumenten zu planen:

CopyExpand

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

Show lessSee more

Scroll to top

Variablen in doppelten Anführungszeichen mit zusätzlichen einfachen Anführungszeichen sind für Zeichenfolgenwerte erforderlich. Wertelisten erfordern eckige Klammern.

Pfad zur Definitionsdatei¶

Sie haben die folgenden Optionen, um auf den Speicherort der Manifest- und Definitionsdateien zu verweisen.

• Von einem Arbeitsbereichspfad

  Die Snowsight-Benutzeroberfläche listet automatisch alle DCM project-Definitionen innerhalb des aktuellen Arbeitsbereichs auf. Sie können einen dieser Pfade auswählen, und die Arbeitsbereiche werden ihn für die Ausführung von DCM-Befehlen verwenden.

  Wenn Sie SQL-Befehle in Arbeitsbereichen manuell ausführen möchten, können Sie auch in jedem Ihrer Arbeitsbereiche auf diesen Pfad verweisen.

  Tipp: Über das 3-Punkt-Menü hinter jeder Datei in Ihrem Arbeitsbereich können Sie den vollständigen Pfad zu dieser Datei in Ihren SQL-Code kopieren.

  Beispiel für einen SQL-Befehl, um ein DCM-Projekt von einem Arbeitsbereichspfad aus zu planen:

  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

• Von einem lokalen Git-Repository-Klon auf Ihrer Festplatte

  Wählen Sie das Verzeichnis aus, das Ihre manifest.yml-Datei enthält, bevor Sie den CLI-Befehl in Ihrer lokalen IDE ausführen. Alternativ können Sie auch ein anderes lokales Verzeichnis angeben, welches das Manifest und die Definitionen enthält, die Sie verwenden möchten.

  Beispiel für einen CLI-Befehl, um ein DCM project aus dem aktuellen Verzeichnis eines lokalen Git-Repositorys zu planen:

  CopyExpand

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

  Show lessSee more

  Scroll to top

  Beispiel für einen CLI-Befehl, um ein DCM project aus einem anderen Verzeichnis in einem lokalen Git-Repository-Klon zu planen:

  CopyExpand

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

  Show lessSee more

  Scroll to top

• Von Ihrem Remote-Repository in einem Workflow

  Dieselbe CLI-Syntax kann verwendet werden, wenn die DCM-Befehle in einem CI/CD-Workflow ausgeführt werden.

  Beispiel für einen CI/CD-Workflow, um ein DCM project von einem lokalen Git-Repository-Klon zu planen:

  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

• Von einem Stagingbereich oder Git-Repository-Klon in Snowflake

  Für den Fall, dass Sie eine Prozedur oder Aufgabe innerhalb von Snowflake ausführen möchten, die DCM-Befehle ausführt, kann dieser SQL-Befehl auf einen absoluten Pfad zu einem Snowflake-Stagingbereich oder einem Git-Repository-Klon innerhalb des Kontos verweisen.

  Bei Git-Repository-Klone sollten Sie möglichst zuerst ALTER GIT REPOSITORY FETCH ausführen, um die neueste Version zu haben.

  '@...'-Pfade können nur bei der Ausführung von DCM SQL-Befehlen verwendet werden.

  Beispiel für einen SQL-Befehl, um ein DCM-Projekt aus einem Stagingbereich oder Git-Repository-Klon in Snowflake zu planen:

  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

Planausgabe¶

Die Standardausgabe des Plans enthält die folgenden Informationen zur Ausführung des Plans im JSON-Format:

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>
          }
        ]
      }
    ]
  }
}

Ein Beispiel für eine Planausgabe:

{
  "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": []
    }
  ]
}

Führen Sie den Befehl DEPLOY aus¶

Um den DEPLOY-Befehl auszuführen, stellen Sie die folgenden Eingaben bereit:

• Der Pfad zur Manifest-Datei.

• Ein Konfigurationsprofil muss benannt werden, wenn im Manifest Konfigurationsprofile definiert sind.

• Optional können Werte für das Konfigurationsprofil die Standardwerte überschreiben.

• Optional ein Bereitstellungs-Alias.

Im Folgenden finden Sie Beispiele für die Ausführung des DEPLOY-Befehls.

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'

Unter Planausgabe finden Sie die Standardausgabestruktur des Plans.

Anzeigen aller von einem DCM project verwalteten Objekte¶

Mit dem Befehl SHOW ENTITIES IN DCM PROJECT können Sie eine Liste aller Snowflake-Objekte anzeigen, die derzeit von einem bestimmten DCM project verwaltet werden. Dies bietet eine Liste mit vollqualifizierten Namen für alle Objekte. Um die Ergebnisse zu sehen, benötigen Sie die READ-Berechtigung für das DCM project und Anzeigeberechtigungen für das verwaltete Objekt selbst.

Sie können LIKE verwenden, um nach Namen zu suchen, oder verwenden Sie einen Flow-Operator, um das Resultset weiter zu verarbeiten oder zu filtern.

Ebenso können Sie SHOW GRANTS und SHOW FUTURE GRANTS anzeigen, die definiert sind und mit diesem Projekt bereitgestellt werden.

Beispiele, um alle Objekte anzuzeigen, die derzeit von einem DCM project verwaltet werden:

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;

Objekte von einem DCM project trennen¶

Verwenden Sie den Befehl ALTER <Objekt> mit der Klausel UNSET DCM PROJECT, um ein Objekt zu trennen, das bereitgestellt wurde und nun von einem DCM project verwaltet wird. Der Befehl entfernt die Zuordnung zwischen dem Objekt und dem DCM project, ohne das Objekt zu löschen. Sie können diesen Befehl verwenden, wenn Sie die Verwaltung eines Objekts durch ein anderes DCM project starten möchten.

Stellen Sie sicher, dass Sie die zugehörige DEFINE-Anweisung aus Ihren Projektdefinitionsdateien entfernen, bevor Sie sie erneut bereitstellen. Andernfalls wird das Objekt wieder in das DCM project integriert.

Beispiel für einen SQL-Befehl zum Trennen eines Objekts von einem DCM project:

ALTER TABLE MY_DB.MY_SCH.MY_TABLE
  UNSET DCM PROJECT;

Sie können gewährte Berechtigungen oder Erwartungen nicht von einem DCM-Projekt trennen.

DCM project löschen¶

Wenn ein DCM project-Objekt gelöscht wird, bleiben alle verwalteten Entitäten, Berechtigungen und Erwartungen als „nicht verwaltet“ bestehen.

DROP DCM PROJECT [IF EXISTS] <my_project>;

snow dcm drop my_project

Best Practices für CI/CD¶

Befolgen Sie diese Vorgehensweisen, wenn Sie Bereitstellungen mit CI/CD-Pipelines automatisieren:

• Ein DCM project, das auf eine nicht produktive Umgebung abzielt, sollte einer anderen Rolle gehören als ihr Gegenstück in der Produktion, um versehentliche Bereitstellungen in der Produktion zu vermeiden.

• Ein DCM project, das auf eine Produktionsumgebung abzielt, sollte einer speziellen Rolle für Produktionsbereitstellungen mit speziell zugeschnittenen Zugriffsrechten gehören, die gerade ausreichen, um alle Objekte im Projekt bereitzustellen.

  • Vermeiden Sie die Verwendung allgemeiner Administratorrollen für DCM project-Eigentümerschaft. Weisen Sie solche Rollen nur Service-Benutzern zu, nicht einzelnen Entwicklern.

  • Weisen Sie die dedizierte Rolle für die Produktionsbereitstellung nur Service-Benutzern zu, nicht einzelnen Entwicklern.

  • Beschränken Sie die Eigentümerschaft auf die Bereitstellungsrolle für die Produktion, um die Unveränderlichkeit der kritischen Infrastruktur oder der Datenprodukte sicherzustellen.

    Wenn die dedizierte Rolle für die Bereitstellung der Produktion anderen Rollen die Eigentümerschaft an Produktionsobjekten gewährt, können Benutzer, denen diese Rollen zugewiesen wurden, die Produktionsobjekte weiterhin ändern oder löschen.

Beispiele für GitHub-Aktionen¶

Dieser Abschnitt enthält Beispiele für GitHub-Aktions-Workflows, die typische CI/CD-Muster für DCM Projects veranschaulichen. Die gleichen Konzepte gelten auch für andere Git-basierte Plattformen wie Azure DevOps, GitLab CI/CD oder Bitbucket-Pipelines – nur die Workflow-Syntax unterscheidet sich.

Jedes Beispiel enthält Bausteine, die Sie auf der Grundlage Ihrer Pipeline-Einrichtung, der Umgebungstopologie und der Anforderungen der Organisation anpassen und kombinieren können.

Die Beispiel-Workflows demonstrieren die folgenden Muster, die auf jedes DCM CI/CD-Setup anwendbar sind:

• Manifest-gesteuerte Konfiguration Jeder Workflow liest account_identifier, project_owner und project_name aus den Manifest-Zielen. Dadurch bleibt die Umgebungskonfiguration an einem Ort gespeichert und es wird vermieden, dass sie über GitHub-Geheimnisse hinweg dupliziert wird.

• Schutz vor Datenlöschung Der Bereitstellungs-Workflow analysiert plan_result.json auf destruktive DROP-Operationen für Objekte, die Daten enthalten, wie Datenbanken, Schemas, Tabellen und Stagingbereiche, und blockiert die Bereitstellung, wenn welche gefunden werden.

• Sequenzielle Heraufstufung vom Stagingbereich zur Produktion Die Bereitstellung der Produktion beginnt erst, nachdem die Bereitstellung des Stagingbereichs erfolgreich war, die dynamischen Tabellen aktualisiert wurden und die Datenqualitätstest bestanden wurden.

• Parsen der strukturierten Planausgabe Workflows verwenden jq, um die Anzahl der Operationen und Objektdomänen aus plan_result.json zu extrahieren, was das Erstellen kundenspezifischer Zusammenfassungen und Prüfungen vereinfacht.

• AI-gestützte Zusammenfassungen snow cortex complete generiert Zusammenfassungen der Ergebnisse des Post-Hook-Skripts und die Aktualisierungsausgabe der dynamischen Tabelle für die GitHub-Aktions-Jobzusammenfassung in natürlicher Sprache.

Bevor Sie diese Beispiel-Workflows ausführen, müssen die folgenden Voraussetzungen erfüllt sein:

• Speichern Sie die DCM project-Dateien in einem Git-Repository.

• Erteilen Sie Benutzerberechtigungen zum Erstellen und Ausführen von GitHub-Aktionen.

• Konfigurieren Sie GitHub-Geheimnisse für die Anmeldeinformationen des Snowflake Service-Benutzers (SNOWFLAKE_USER, SNOWFLAKE_PASSWORD oder ein persönliches Zugriffstoken).

• Konfigurieren Sie GitHub-Variablen für den Pfad zum DCM project-Ordner (DCM_PROJECT_PATH).

• Konfigurieren Sie GitHub-Umgebungen für jedes Manifest-Ziel (z. B. DCM_STAGE, DCM_PROD_US).

Hinweise zum Einrichten einer Snowflake-Verbindung in GitHub-Aktionen finden Sie in der ersten Hälfte des Blogeintrags: `Ein praktischer Leitfaden zu GitHub-Aktionen CI/CD<https://medium.com/@uche.nkadi/automate-your-dbt-project-on-snowflake-a-practical-guide-to-github-actions-ci-cd-a366b6e061e5>`_.

Im `snowflake-labs DCM -Repository<https://github.com/Snowflake-Labs/snowflake_dcm_projects/GitHub_workflows>`_ finden Sie einige GitHub-Aktions-Workflows, die den gesamten CI/CD-Lebenszyklus für DCM Projects abdecken.

Alle Beispiel-Workflows lesen die Snowflake account_identifier- und``project_owner``-Rolle direkt aus den Manifest-Zielen mit yq, sodass die umgebungsspezifische Konfiguration in der versionskontrollierten manifest.yml und nicht in duplizierten GitHub-Geheimnissen existiert. Nur die Anmeldeinformationen des Service-Benutzers werden als Geheimnisse gespeichert.