DCM Projects-Dateien und -Vorlagen¶

Projektdefinitionen und Projektobjekten zuordnen¶

DCM Projects-Definitionsdateien sind nicht streng an ein bestimmtes DCM project-Objekt gebunden. Sie können denselben Satz von Definitionen für die Bereitstellung in mehreren Projekten verwenden, entweder in verschiedenen Snowflake-Konten oder indem Sie auf verschiedene Konfigurationsprofile verweisen. Zum Beispiel können dieselben Definitionsdateien in einem Repository-Zweig in DEV- und PROD-Konten bereitgestellt werden, wie in der folgenden Abbildung gezeigt.

Auf ähnliche Weise können Sie ein DCM Projects-Objekt ausführen, indem Sie auf Definitionsdateien aus verschiedenen Pfaden verweisen. Zum Beispiel kann IhreCI/CD-Automatisierung Definitionen aus Ihrem Hauptzweig bereitstellen, und Sie können einen PLAN aus Ihren lokalen Definitionsdateien für dasselbe Projekt manuell ausführen, um zu prüfen, wie sich Ihre Definitionen von der letzten Bereitstellung unterscheiden. Sie können diesen Ansatz auch für manuelle Ad-hoc-Bereitstellungen von anderen Zweigen oder lokalen Pfaden verwenden.

Makros¶

Makrodateien sind beliebigeSQL-Dateien, die sich im Ordner macros und seinen Unterordnern befinden. Sie können nur Makros enthalten.

Beispiel für die Verzeichnisstruktur eines DCM project mit Makrodateien ist:

My_dcm_project
 |_ manifest.yml
 |_ sources
    |_ definitions
       |_ my_definitions.sql
    |_ macros
       |_ my_global_macros.sql

Ähnlich wie bei Funktionen in regulären Programmiersprachen helfen Makros dabei, häufig verwendete Codeelemente in wiederverwendbaren Funktionen zu organisieren, um so Wiederholungen zu vermeiden und das DRY-Prinzip (nicht sich selbst wiederholen) zu befolgen. Makros in DCM Projects funktionieren auf die gleiche Weise wie `Jinja2-Makros<https://jinja.palletsprojects.com/en/stable/templates/#macros>`_ mit den folgenden Ausnahmen:

• Dedizierter Speicherort für Makrodateien im Ordner macros.

• Makros, die in Makrodateien definiert sind, sind automatisch auch in anderen Quelldateien sichtbar. Das Jinja-Tag `import<https://jinja.palletsprojects.com/en/stable/templates/#import>`_ ist nicht zulässig.

• Doppelte Definition eines Makros mit demselben Namen wird erkannt und abgelehnt.

Kommentare zur Vorlage¶

In SQL-Befehlen können Sie -- vor Ihrem Code hinzufügen, um die Zeile auszukommentieren. Jinja verarbeitet weiterhin Variablen innerhalb des SQL-Codes, lässt aber die SQL-Kommentare aus.

Beispielsweise der folgende Jinja-Code:

-- hello {{ project_owner_role }}

Wird gerendert als:

-- hello DCM_DEVELOPER

Auskommentierte Befehle werden in SQL nicht ausgeführt. Sie können Kommentare zu Vorlagen verwenden, um Jinja-Vorlagen zu debuggen, ohne Ihren SQL-Code zu beeinträchtigen.

Um Jinja-Code beim Rendern zu ignorieren, fügen Sie # innerhalb von öffnenden und schließenden Klammern hinzu, wie im folgenden Beispiel gezeigt:

{# This Jinja comment will not appear in the rendered output. #}

Konfigurationen¶

Wenn Sie Vorlagen in Ihren Objektdefinitionen verwenden, haben Sie die folgenden Optionen:

• Weisen Sie Variablen zur Laufzeit Werte zu.

• Definieren Sie verschiedene Konfigurationsprofile unter templating: configurations: in der manifest.yml. Jedes Ziel kann über templating_config auf eine Konfiguration verweisen. Weitere Details dazu finden Sie unter Konfiguration von Projektvorlagen.

  Wenn Konfigurationsprofile definiert sind und ein Ziel eines über templating_config referenziert, wird die Konfiguration automatisch angewendet, wenn Sie dieses Ziel verwenden. Weitere Beispiele finden Sie unter DCM project planen.

  Der primäre Anwendungsfall für Konfigurationsprofile in DCM Projects sollte auf verschiedene Umgebungen abzielen. Mit Konfigurationsprofilen können Sie Folgendes tun:

  • Stellen Sie denselben Code in mehreren Umgebungen bereit.

  • Testen Sie den Produktionscode in einer Nicht-Produktions-Umgebung in reduziertem Umfang.

  • Verwalten mehrerer isolierter Umgebungen im selben Konto

  Nicht alle Vorlagenkonfigurationen müssen von einem Zielprofil referenziert werden. Sie können nicht verwendete Konfigurationen behalten, um die Vorlagenkonfiguration für Ihr Ziel zu wechseln.

• Definieren Sie gemeinsame Standardwerte unter templating: defaults:, um die Wiederholung allgemeiner Variablen in verschiedenen Konfigurationen zu vermeiden. Weitere Details dazu finden Sie unter Konfiguration von Projektvorlagen.

• Überschreiben Sie bestimmte Variablen mit Einmalwerten zur Laufzeit unter Verwendung des --variable-Flag in der CLI.

Variablen werden mit einer dreistufigen Hierarchie aufgelöst: Globale Standardwerte < Konfigurationsvariablen < Laufzeit-Ausführungsvariablen.

Wörterbücher¶

DCM Projects-Vorlagen unterstützen Wörterbücher als Variablenwerte und ermöglichen so eine strukturierte Konfiguration für komplexe Bereitstellungen mit mehreren Mandanten oder mehreren Ressourcen.

Durch Gruppieren zusammengehöriger Konfigurationsdetails in Wörterbüchern erhalten Sie Folgendes:

• Granulare Kontrolle: Wenden Sie bestimmte Einstellungen, wie z. B. Warehouse-Größen, Aufbewahrungsrichtlinien und Berechtigungen, auf einzelne Ressourcen an, ohne für jede Variante eine eigene Logik zu schreiben.

• Saubere Code-Basis: Ersetzen Sie sich wiederholende, fest codierte Skripte durch dynamische Schleifen, die sich je nach Konfiguration anpassen.

• Skalierbarkeit: Richten Sie neue Teams oder Ressourcen ein, indem Sie Einträge zu Ihrer Konfiguration hinzufügen, anstatt die Bereitstellungspipelines umzustrukturieren.

templating:
  defaults:
    user: "GITHUB_ACTIONS_SERVICE_USER"
    wh_size: "X-SMALL"
  configurations:
    PROD:
      env_suffix: ""
      project_owner_role: "DCM_PROD_DEPLOYER"
      teams:
        - name: "Marketing"
          wh_size: "MEDIUM"
          data_retention_days: 14
          needs_sandbox_schema: true
        - name: "Finance"
          wh_size: "X-LARGE"
          data_retention_days: 90
          needs_sandbox_schema: false
        - name: "HR"
          data_retention_days: 30
          needs_sandbox_schema: false

-- loop through team dictionaries
{% for team in teams %}
    {% set team_name = team.name | upper %}

    -- inject dictionary values directly into object properties
    define schema DCM_DEMO_1{{env_suffix}}.{{team_name}}
        comment = 'using JINJA dictionary values'
        data_retention_time_in_days = {{ team.data_retention_days }};

    -- pass the name to your macro
    {{ create_team_roles(team_name) }}

    define table DCM_DEMO_1{{env_suffix}}.{{team_name}}.PRODUCTS(
        ITEM_NAME varchar,
        ITEM_ID varchar,
        ITEM_CATEGORY array
    )
    data_metric_schedule = 'TRIGGER_ON_CHANGES';

    {% if team_name == 'HR' %}
        define table DCM_DEMO_1{{env_suffix}}.{{team_name}}.EMPLOYEES(
            NAME varchar,
            ID int
        )
        comment = 'This table is only created in HR';
    {% endif %}

    -- use dictionary booleans to deploy optional infrastructure
    {% if team.needs_sandbox_schema | default(false) %}
        define schema DCM_DEMO_1{{env_suffix}}.{{team_name}}_SANDBOX
            comment = 'Sandbox schema defined via dictionary flag'
            data_retention_time_in_days = 1;
    {% endif %}

{% endfor %}