Unser Partner dbt hat kürzlich einige häufig gestellte Fragen zu Cloud-Umgebungen beantwortet. In diesem Blog teilen wir sie mit Ihnen.

Wie verwalte ich Umgebungen in meinem dbt Cloud Projekt? Wie viele brauche ich? Wie mappe ich meine Data-Warehouse-Struktur auf die Umgebungen in der dbt Cloud? Und was haben Git-Branches mit meinen dbt Cloud Umgebungen zu tun?

All diese Fragen werden hier einfach und verständlich beantwortet. Wenn es um die Verwaltung Ihrer dbt Cloud-Umgebungen geht, gibt es nicht die eine Lösung, die für alle Teams passt. Betrachten Sie dies daher als einen Leitfaden, der Sie durch einige von uns empfohlene Optionen für die Architektur Ihrer dbt Cloud-Umgebung führt.

Dieser Leitfaden hat die folgenden drei Hauptziele:

1. Bereitstellung der dbt Empfehlungen für das Management von dbt Cloud-Umgebungen.
2. Veranschaulichung dieser Empfehlungen durch umfassende Beispiele.
3. Jeder Schritt soll erläutern, warum dbt gerade diesen Ansatz empfiehlt. So können Sie entscheiden, wann und wo Sie von den Empfehlungen abweichen sollten, um den spezifischen Anforderungen Ihres Unternehmens besser gerecht zu werden.

Wie viele Cloud-Umgebungen benötige ich wirklich?

Umgebungen definieren die Art und Weise, wie dbt Ihren Code ausführt, einschließlich:

• Die Version von dbt, die ausgeführt wird.
• Die Version Ihres Codes, die ausgeführt wird.
• Die Verbindungsinformationen für Ihr Warehouse.
• Es gibt zwei Arten von Umgebungen in der dbt Cloud:
  • Entwicklung – die Umgebung, in der Sie in der IDE an einem Entwicklungszweig arbeiten.
  • Deployment – die Umgebung, in der ein dbt Cloud Job ausgeführt wird.

In dieser Anleitung konzentrieren wir uns auf die Deployment-Umgebungen, die bestimmen, wie Ihr Projekt ausgeführt wird, wenn ein dbt Cloud-Job ausgeführt wird.

Abhängig von Ihrem Git-Workflow und Ihrer Teststrategie werden Sie zwischen einer oder mehreren Deployment-Umgebungen wählen. Hier erhalten Sie einen Überblick über die Funktionsweise dieser beiden Deployment-Strategien. In den einzelnen Abschnitten dieses Leitfadens können Sie sich jedoch detailliert mit den Unterschieden zwischen den beiden Deployment-Optionen auseinandersetzen.

TL;DR – Eine Deployment-Umgebung

dbt empfiehlt generell, mit den Grundlagen zu beginnen. Eine Deployment-Umgebung ist in der Regel der einfachste und wartungsfreundlichste Ansatz für den Anfang. Dieser Ansatz funktioniert gut, wenn …

• Sie nur in einer einzigen Umgebung innerhalb Ihres Data Warehouse geplante Jobs ausführen müssen.
• Sie einen einzigen primären Zweig verwenden und eine direkte Transportstrategie verfolgen (Dev -> Prod).

Mit dieser Option werden Ihre Produktionsaufträge und Ihre Slim CI-Aufträge, die die Codeintegrität sicherstellen, in einer einzigen Deployment-Umgebung verwaltet.

TL;DR – Mehrere Bereitstellungsumgebungen

Dieser Ansatz ist etwas komplexer und kann den Entwicklungsprozess verlangsamen, bietet aber eine zusätzliche Sicherheitsebene, die diesen Kompromiss wert sein kann. Dieser Ansatz funktioniert gut, wenn …

• Ihre Organisation mehrere langlebige Git-Zweige unterhält, um zu kontrollieren, wie und wann Änderungen getestet und in die Produktion übernommen werden.
  • Einige Organisationen folgen einem Dev -> QA -> Prod Release-Zyklus – wenn das auf Ihre Organisation zutrifft, ist dieser Ansatz wahrscheinlich der richtige für Sie.
• Der Output Ihres dbt-Projekts Input für andere Systeme ist und Sie viele Änderungen an einem stabilen, langlebigen Staging-Datensatz in einer Vorproduktionsumgebung testen und validieren müssen.

Die beiden Optionen werden in den folgenden Abschnitten genauer betrachtet, einschließlich der Vorteile, Kompromisse und Schritte, die für die Implementierung in der dbt Cloud erforderlich sind.

So sieht es aus

1. Sie haben eine einzige Deployment-Umgebung, in der dbt-Nutzer auf die dbt-Cloud-IDE zugreifen und Änderungen an ihrem Code in Funktionszweigen vornehmen können, die von Ihrem Standardzweig in Ihrem Repository (normalerweise der Hauptzweig) erstellt wurden.
2. Sie haben eine einzige Deployment-Umgebung (nennen wir sie „Produktion“), in der Ihre geplanten Jobs mit Referenz auf den Hauptzweig ausgeführt werden.
3. Sie haben auch einen Slim CI Job, der jedes Mal gestartet wird, wenn Sie einen PR öffnen, um einen Funktionszweig mit dem Hauptzweig zusammenzuführen. Dieser Slim CI Job kann in Ihrer dbt-Umgebung „Produktion“ ausgeführt werden.

ZWISCHENINFO

☁️ Slim CI Jobs laufen in einem eigenen benutzerdefinierten Schema für jeden PR, so dass es keine Kollisionen mit Ihren Produktionsschemata gibt.

Tabelle der Grundeinstellungen für eine Deployment-Umgebung

Git Arbeitsablauf

Git Ablaufdiagramm für eine Deployment-Umgebung

1. In der dbt Cloud IDE arbeiten die Entwickler an Feature Branches, die aus dem Main Branch (feature_a, feature_b, feature_c oben) erzeugt werden.
2. Wenn der Code fertig ist, öffnet der Entwickler einen PR, um den Feature-Zweig mit dem main Branch zusammenzuführen.
3. Slim CI Job startet automatisch und testet die Änderungen im PR.
4. Wenn der Slim CI Job erfolgreich ist und das Team bereit ist, die Änderungen in die Produktion zu übernehmen, wird der PR direkt mit dem Hauptzweig zusammengeführt. Bei der nächsten Ausführung eines Produktionsjobs werden die Änderungen übernommen und ausgeführt.

dbt Cloud Einrichtung

1. Erstellen Sie Ihre Entwicklungsumgebung, um die dbt Cloud IDE zu betreiben. Es sind keine zusätzlichen Anpassungen notwendig!
2. Erstellen Sie Ihre Produktionsumgebung.
3. Definieren Sie Ihre dbt Cloud Jobs in der Produktionsumgebung aus Schritt 2.

• • Produktionsjob(s): Sie müssen mindestens einen geplanten Job einrichten, der Ihr Projekt in Ihre Produktionsdatenbank/-schema einspeist. Je nach den SLAs Ihres Unternehmens können Sie mehrere Jobs erstellen.
  • Slim CI Job: Im Gegensatz zu den Produktionsjobs, die über den Scheduler ausgelöst werden, wird dieser Job ausgelöst, wenn PRs in Ihrem Repository geöffnet werden. Aktivieren Sie diese Option, indem Sie auf der Registerkarte webhooks im Abschnitt triggers die Option run on pull requests? auswählen.

ZWISCHENINFO

Dieser Job muss auch auf einen der Produktionsjobs verweisen, die Sie in Schritt 3a erstellt haben. Dadurch können Sie die state Modifikatoren in Ihrer Selektionssyntax verwenden, um nur die Änderungen auszuführen, die durch Ihren PR eingeführt wurden.

Wann dies gut funktioniert

Dieser Ansatz wird für die meisten Anwendungsfälle empfohlen, da er es ermöglicht, Codeänderungen schnell in Produktion zu bringen und dabei sicher zu sein, dass ihnen vertraut werden kann. Mit dieser Option können mehrere Entwickler einfach und vertrauensvoll zur gleichen Codebasis beitragen.

Wann das nicht so gut funktioniert

• Sie haben einen formalen QA-Prozess, bevor Sie den Code in Produktion geben.
• Sie wollen kontrollieren, wann Features für die Produktion freigegeben werden.
• Sie müssen geplante Jobs aufgrund von Abhängigkeiten von externen Systemen in vielen Umgebungen ausführen.
  Ihr Unternehmen hat z.B. viele Anwendungen, die Datenänderungen in einer niedrigeren Nicht-Produktionsumgebung konsumieren und testen, bevor die Änderungen in die Produktion übernommen werden.

Mehrere Deployment-Umgebungen

So funktioniert es

1. Sie haben eine einzige Entwicklungsumgebung, in der dbt Benutzer auf die dbt Cloud IDE zugreifen und Änderungen an ihrem Code vornehmen können. Sie möchten jedoch die Einstellungen für benutzerdefinierte Zweige aktualisieren, um sicherzustellen, dass Entwickler Featurezweige aus einem Nicht-Produktionszweig erstellen. In diesem Beispiel nennen wir dies den QA-Zweig.
2. Sie haben eine QA-Bereitstellungsumgebung, in der geplante Jobs aus dem QA-Zweig ausgeführt werden, die Ihr dbt-Projekt in einem Repository vor der Produktion bereitstellen.
3. Sie haben eine Produktionsbereitstellungsumgebung, in der geplante Aufträge vom main Zweig ausgeführt werden, der Ihr dbt-Projekt an Ihrem Produktionslagerort bereitstellt.
4. Sie haben mehrere Slim CI Jobs (einen in jeder Deployment-Umgebung), um sicherzustellen, dass Änderungen in jedem Zweig getestet werden.

Tabelle der Grundeinstellungen für viele Deployment-Umgebungen

Git Workflow

Git Ablaufsdiagramm für viele Deployment-Umgebungen

1. In der dbt Cloud IDE arbeiten die Entwickler an Feature Branches, die aus dem qa Branch (feature_a, feature_b, feature_c oben) erzeugt werden.
2. Wenn der Code fertig ist, öffnet der Entwickler einen PR, um den Feature-Zweig mit dem qa-Zweig zusammenzuführen.
3. Der erste Slim CI Job wird automatisch gestartet, um die Änderungen im PR zu testen. Dieser Job wird in einen regelmäßig geplanten Job in der QA-Umgebung verschoben und in der QA-Bereitstellungsumgebung ausgeführt.
4. Wenn der Slim CI Job erfolgreich ist und das Team bereit ist, die Änderungen bereitzustellen, wird der PR in die QA-Umgebung zusammengeführt.
5. Geplante Jobs werden in der QA-Bereitstellungsumgebung ausgeführt, um sicherzustellen, dass die neuen Änderungen wie geplant funktionieren.
6. Wenn alle Featurezweige für ein bestimmtes Release (z.B. Sprint) erfolgreich in die QA zusammengeführt wurden und in der QA-Bereitstellungsumgebung fehlerfrei laufen, öffnet ein Teammitglied einen PR, um qa → main zusammenzuführen.
7. Der zweite Slim CI Job wird automatisch gestartet, um die Änderungen im PR zu testen. Dieser Job wird in einen regulär geplanten Job in der Produktionsumgebung verschoben und in der Produktionsumgebung ausgeführt.
8. Wenn der zweite Slim CI Job erfolgreich ist und das Team bereit ist, die Änderungen bereitzustellen, wird der PR in die main Umgebung zusammengeführt.
9. Überwachen Sie die geplanten Jobs in der Produktionsumgebung, die im main Zweig ausgeführt werden. Voilà! Alle Änderungen sind freigegeben und stehen Ihren Stakeholdern zur Verfügung.

dbt Cloud Einrichtung

1. Erstellen Sie Ihre Entwicklungsumgebung für die dbt Cloud IDE.Hier werden wir einen benutzerdefinierten Zweig einrichten, so dass Benutzer ihre Feature-Zweige in der IDE von qa anstatt von main erstellen. Klicken Sie auf only run on a custom branch in General settings, geben Sie qa in Custom Branch ein.
2. Richten Sie Ihre QA-Deployment-Umgebung ein.Die Einstellungen für den benutzerdefinierten Zweig sind die gleichen wie für die Entwicklungsumgebung in Schritt 1. Alle geplanten Jobs in der QA-Bereitstellungsumgebung verwenden den Code aus dem qa-Zweig, wenn sie ausgeführt werden.
3. QA-Jobs definieren
   1. QA-Job(s): Sie sollten mindestens einen geplanten Job erstellen, der ungefähr täglich ausgeführt wird. Dies stellt sicher, dass der gesamte Code fehlerfrei ausgeführt wird, bevor Sie ihn für die Produktion freigeben, und dass auch der erste Slim CI Job ausgeführt wird.
   2. Slim CI Job: Wie oben wird dieser Job ausgelöst, wenn PRs in Ihrem Repository geöffnet werden. Aktivieren Sie diese Option, indem Sie run on pull requests? auf der Registerkarte webhooks im Abschnitt triggers auswählen. Da wir die benutzerdefinierte Verzweigung in der QA-Umgebung verwenden, sollten Sie auch die zweite Option Nur bei benutzerdefinierter Verzweigung ausführen (standardmäßig aktiviert) auswählen – das bedeutet, dass nur PRs, die für die QA-Verzweigung erstellt wurden, diesen Job auslösen, und nicht jeder PR.Dieser Job muss auch einen der in Schritt 3a erstellten QA-Jobs zurückstellen. Dies ermöglicht die Verwendung des Modifikators state in Ihrer Auswahlsyntax, um nur die Änderungen auszuführen, die durch Ihren PR eingeführt wurden.
4. Einrichten der ProduktionsbereitstellungsumgebungAuch hier verwenden wir die gleichen Einstellungen für die benutzerdefinierte Verzweigung wie in den anderen Umgebungen, aber wir definieren die benutzerdefinierte Verzweigung als main Verzweigung. Obwohl der main Zweig die Standardeinstellung ist, ermöglicht uns die Einstellung dieses Wertes, den CI-Job im nächsten Schritt richtig einzurichten.
5. Produktionsaufträge definieren
   1. Produktions-Job(s): Sie müssen mindestens einen geplanten Job einrichten, der Ihr Projekt in Ihren Produktionsdatenbanken/Schemata bereitstellt. Abhängig von den SLAs Ihres Unternehmens können Sie mehrere Produktionsaufträge anlegen.
   2. Produktion Slim CI Job: Wie oben wird dieser Job ausgelöst, wenn PRs in Ihrem Repository geöffnet werden. Aktivieren Sie diese Option, indem Sie run on pull requests? auf der Registerkarte webhooks im Abschnitt triggers auswählen. Da wir in der QA-Umgebung die Einstellung für die benutzerdefinierte Verzweigung verwenden, müssen wir auch die zweite Option Nur bei benutzerdefinierter Verzweigung ausführen auswählen – das bedeutet, dass nur PRs, die gegen die main Verzweigung erstellt wurden, diesen Job auslösen, und nicht alle PRs.Dieser Job muss auch einen der in Schritt 5a erstellten QA-Jobs zurückstellen. Dies ermöglicht es Ihnen, den state Modifikator in Ihrer Auswahlsyntax zu verwenden, um nur die Änderungen durchzuführen, die durch Ihre PR eingeführt wurden.

Wann dies gut funktioniert

Dieser Ansatz eignet sich gut, wenn es wichtig ist, Benutzerakzeptanz- und Integrationstests in einer Vorproduktionsumgebung durchzuführen. Mit diesem Ansatz können Sie geplante Jobs in vielen Umgebungen auf Ihrem Data Warehouse ausführen.

Wann es nicht so gut funktioniert

Dieser Ansatz kann die Zeit verlangsamen, die benötigt wird, um eine neue Funktion in Produktion zu bringen, da zusätzliche Schritte im Bereitstellungsprozess und zusätzliche Zweige für die Pflege erforderlich sind. Bedenken Sie, dass die zusätzliche Komplexität Ihres Bereitstellungsprozesses zu einer Verlangsamung Ihres Veröffentlichungszyklus führen kann.

Schlussfolgerung

Auch wenn es keine allgemeingültige Antwort auf die Frage gibt, wie Sie Ihre dbt-Cloud-Umgebung einrichten sollten, so ist sie doch flexibel genug, um nahezu jeden Codepublizierungs-Workflow in Ihrem Unternehmen zu unterstützen.

Wir würden uns freuen, von Ihnen zu hören, wie Sie Ihre Deployment-Infrastruktur in der dbt Cloud eingerichtet haben. Gerne sind wir Ihnen dabei auch behilflich!

Quelle: dbt