dbt Cloud einrichten: Git, Verbindungen, DEV, CI und Deployment

Quellen- und Versionsstand: 26.10.2026. Snowflake: laufender Cloud-Dienst; tatsächlichen Accountstand mit CURRENT_VERSION() dokumentieren. dbt: v2-Generation sowie separate Python-v1-Linie; konkretes Paket/Adapter-Paar beziehungsweise Cloud-Engine und Release-Track selbst erfassen. Updates können Menüs und Verhalten ändern. Redaktionelle Anleitung, kein ausgeführter Plattformtest.

Cloud ist ein eigener Betriebsweg

Die dbt platform, oft dbt Cloud genannt, stellt gehostete Arbeitsabläufe bereit. Die konkreten Möglichkeiten hängen von Tarif, Engine und Release-Track ab. Ein lokal erfolgreiches dbt-Projekt ist nicht automatisch ein korrekt konfigurierter Cloud-Job. Diese Anleitung verwendet dieselben synthetischen Snowflake-Daten wie Teil 2; reale Kundendaten sind nicht nötig.

Beginne mit Projekt, Repository und Snowflake-Verbindung in der dbt-Plattform. Die folgenden Schritte richten diese Verbindung und den ersten Modelllauf ein.

1. Projekt und Git-Anbindung vorbereiten

1. Im freigegebenen dbt-Account das Projekt anlegen beziehungsweise ein ausdrücklich vorgesehenes Testprojekt verwenden. Region, Tarif und administrierende Rolle aufnehmen.
2. Das genehmigte Repository mit einer auf den benötigten Umfang begrenzten Integration anbinden. Wer darf Änderungen einreichen, prüfen und zusammenführen? Diese Rollen festhalten.
3. Einen Entwicklungsbranch für den Pilot anlegen. Ein verwaltetes Beispielrepository kann einen Einstieg erleichtern, ersetzt aber keine vereinbarten Rechte und Freigaben.
4. Die drei Projektdateien aus dem lokalen Teil übernehmen oder bewusst neu anlegen: Projektdefinition, Modell und Source-/Testdefinition. Eine lokale profiles.yml mit Zugangsinformationen gehört nicht in dieses Repository.

Die Snowflake-Quickstart-Hilfe zeigt den grundsätzlichen Projektablauf. Menübezeichnungen können abweichen; entscheidend sind gespeicherte Verbindung, tatsächliche Zielumgebung und wirksame Identität.

2. Verbindung und Entwicklung prüfen

Verbindung speichern und mit der Entwicklungsidentität testen. Danach das Modell orders bauen. Erwartet sind drei Zeilen und Summe 50 im tatsächlich ermittelten DEV-Ziel. Wird ein anderes Schema verwendet als geplant, zuerst Konfiguration und Namensregeln klären, nicht einfach weitere Rechte vergeben.

3. Optional: Deployment-Umgebung separat konfigurieren

Ein Deployment-Job ist die unbeaufsichtigte Ausführung eines ausgewählten Projektstands. Dafür braucht ihr eine eigene technische Identität mit passend eingeschränktem Zielzugriff. Interaktives Browser-SSO aus einer Entwicklersitzung ist kein Scheduler-Zugang.

1. Zielumgebung mit eigenem Datenbank-/Schemabezug und freigegebenem Warehouse anlegen. Nicht die persönlichen Entwicklungszugänge kopieren.
2. Technische Anmeldung nach der aktuellen Snowflake-/dbt-Hilfe und Firmenvorgabe einrichten; Secret-Verweis, Rotation und Vertretung dokumentieren.
3. Branch beziehungsweise freigegebenen Commit und Engine/Release-Track festlegen.
4. Einen manuellen begrenzten Job mit dbt build --select orders ausführen. Ziel, Identität und reale Artefakte prüfen, bevor ein Zeitplan aktiviert wird.
5. Im tatsächlichen Joblauf Ziel, Ausführungsrolle, verwendeten Commit und Ergebnis kontrollieren. Bei Bedarf Lauf-ID und Log für die Fehlersuche behalten.

Die Deployment-Job-Hilfe beschreibt aktuelle Konfigurationsmöglichkeiten. Ein gespeicherter Job ist noch kein Laufnachweis.

4. Optional: CI einrichten und testen

CI soll Änderungen vor Übernahme prüfen. Nutzt ein eigenes CI-Ziel mit begrenzten Rechten. Die CI-Hilfe beschreibt die Funktionen der Plattform; tatsächlichen Tarif und Repository-Integration bestätigen.

Für den ersten Pilot einen klaren vollständigen Prüfumfang wählen. Später kann State-Auswahl sinnvoll sein; sie benötigt ein passendes Vergleichsartefakt. Ein Verweis auf ein beliebiges altes Manifest beweist keine korrekte Änderungsauswahl. Deferral und abweichende Engine-/Artefaktstände gesondert prüfen.

Verabredet konkret: Welche Fehler verhindern Merge oder Veröffentlichung? Wer darf eine Ausnahme entscheiden? Erzeugt einen kontrollierten Testfehler und belegt, dass genau die vereinbarte Grenze greift. „Ein CI-Job existiert“ ist kein Beleg für eine wirksame Freigabesperre.

5. Optional: Zeitplan und Fehlermeldung prüfen

Zeitzone, Sommerzeit und fachlichen Fertigstellungstermin getrennt dokumentieren. Vor jedem produktiven Zeitplan einen manuellen Lauf und einen Alarmfall nachweisen. Ansprechpartner und Vertretung bestätigen den Empfang der Fehlermeldung.

Die Browser-Einrichtung ist abgeschlossen, wenn Verbindung und erster Entwicklungsbuild funktionieren. Deployment, CI und Zeitpläne ergänzt du nach Bedarf. Die Cloud-/Deployment-Wissenschecks helfen bei der Vertiefung; sie sind optional.

Herstellerquellen

• dbt: Snowflake quickstart
• dbt: Deployment jobs
• dbt: Continuous integration

Wenn Fivetran die Snowflake-Quellen befüllt

Der dbt-Cloud-Job darf nicht nur „zur ungefähr passenden Uhrzeit“ laufen. Dokumentiert, welche Fivetran-Verbindungen welche dbt-Sources befüllen, was als ausreichend aktuell gilt und wer bei einem Ladefehler reagiert. Eine erfolgreiche Anmeldung in Snowflake belegt keine vollständigen Quelldaten.

Entscheidet, ob dbt Cloud eigenständig orchestriert wird oder über eine passende Fivetran-Integration gestartet wird. Fivetran-hosted Transformations for dbt ist ein anderer Betriebsweg als ein dbt-Cloud-Job. Unterstützte Versionen, Zugang und Zeitpläne konkret prüfen; keine doppelten Trigger für denselben Auftrag einrichten. Offizielle Integrationsübersicht.

Nach einem abgeschlossenen Sync Modelle und Tests für den vereinbarten Ausschnitt ausführen. Bei fehlendem oder überaltertem Stand die Veröffentlichung gemäß vereinbartem Verfahren zurückhalten. Der vollständige Quellenweg steht im bestehenden Fivetran-Einrichtungskapitel.