Looker CI/CD-Nutzung und ‑Workflow mit mehreren Ebenen

Auf dieser Seite wird beschrieben, wie Sie einen mehrstufigen CI/CD-Workflow in Looker verwenden, nachdem er installiert und konfiguriert wurde.

In dieser Anleitung wird ein dreistufiges System verwendet, das aus Entwicklung, Qualitätssicherung und Produktion besteht. Sie können die gleichen Prinzipien jedoch auch auf ein zwei- oder vierstufiges System anwenden.

In dieser Anleitung wird auch davon ausgegangen, dass Sie GitHub als Git-Anbieter verwenden. Sie können andere Git-Anbieter verwenden, um einen CI/CD-Workflow zu erstellen. Sie müssen jedoch über das Fachwissen verfügen, um diese Anleitung für Ihren Anbieter zu ändern.

Workflowübersicht

LookML-Entwickler schreiben zuerst Code in ihrem Entwicklungszweig, der normalerweise etwa dev-my-user-ydnv heißt, testen ihre Änderungen mit Looker Continuous Integration (oder indem sie manuell eine CI-Suite ausführen) und committen ihren Code. Schließlich öffnen sie eine Pull-Anfrage, um ihren Code mit dem main-Branch zusammenzuführen.

Wenn die Pull-Anfrage geöffnet wird, wird der Entwickler zu GitHub weitergeleitet. Der Entwickler sollte einen aussagekräftigen PR-Titel im Stil von Conventional Commits schreiben und der Beschreibung einen Kommentar hinzufügen, der im Changelog enthalten sein soll. Wenn Pull-Anfrage-Trigger konfiguriert ist, wird die Pull-Anfrage automatisch von Looker Continuous Integration validiert. Entwickler können die Ergebnisse in Looker oder in GitHub ansehen.

Als Nächstes sollte der Entwickler einen Prüfer in GitHub auswählen. Der Prüfer erhält eine Benachrichtigung und kann seine Rezension dem Pull-Request hinzufügen. Wenn der Prüfer die Änderung genehmigt, wird der PR mit dem Branch main zusammengeführt. Ein WebHook wird aufgerufen und die Änderung ist jetzt in der Entwicklungsumgebung sichtbar.

Die Release Please-Automatisierung wird automatisch ausgeführt und öffnet einen zweiten PR, um einen neuen getaggten Release zu erstellen. Wenn bereits eine Pull-Anfrage für diesen Zweck geöffnet ist, wird sie von Release Please aktualisiert. Der Release-PR hat eine Versionsnummer und ein Changelog mit den Titeln und Beschreibungen der enthaltenen Änderungen.

Wenn der von Release Please generierte PR genehmigt und zusammengeführt wird, wird ein neues Versions-Tag generiert und das Changelog wird mit dem main-Branch zusammengeführt. Die QA- und Produktionsinstanzen von Looker können diese Version mit dem erweiterten Bereitstellungsmodus auswählen.

Best Practices für die Nummerierung von Releases und die Benennung von Commits

Die Releases und die zugehörigen Tags können beliebig benannt und nummeriert werden. Hier wird jedoch Semantic Versioning verwendet, was sehr empfehlenswert ist, da es gut mit dem Release Please-Plug-in funktioniert.

Bei der semantischen Versionsverwaltung besteht die Version aus drei Zahlen, die durch Punkte getrennt sind: MAJOR.MINOR.PATCH

  • PATCH wird jedes Mal erhöht, wenn in einer Version ein Fehler behoben wird.
  • MINOR wird erhöht und PATCH wird auf null zurückgesetzt, wenn in der Version eine Funktion hinzugefügt oder verbessert wird, die abwärtskompatibel ist.
  • MAJOR wird inkrementiert und sowohl MINOR als auch PATCH werden auf null gesetzt, wenn eine Funktion hinzugefügt wird, die nicht abwärtskompatibel ist.

Conventional Commits ist ein System zum Benennen von Commits nach den Auswirkungen, die sie auf Endnutzer haben. Die Verwendung von konventionellen Commit-Namen ist zwar nicht erforderlich, aber auch für das Release Please-Plug-in nützlich.

Bei der herkömmlichen Commit-Benennung wird jeder Commit-Nachricht ein Indikator für den Umfang der Änderung vorangestellt:

  • Eine Fehlerkorrektur wird mit fix: wie fix: set proper currency symbol on sale_amt format angegeben.
  • Eine neue Funktion wird mit feat: gekennzeichnet, z. B. feat: added explore for sales by territory.
  • Eine Funktion mit einer wichtigen Änderung wird mit feat!: wie feat!: rewrote sales explore to use the new calendar view gekennzeichnet.
  • Wenn die Dokumentation aktualisiert, aber LookML nicht geändert wird, beginnt die Commit-Nachricht mit doc:.

Wenn Conventional Commits konsistent verwendet werden, ist es in der Regel einfach, die nächste semantische Nummer zu bestimmen. Wenn das Commit-Log nur aus fix:- und doc:-Commits besteht, sollte die PATCH erhöht werden. Wenn ein feat:-Commit vorhanden ist, sollte MINOR inkrementiert werden. Wenn ein feat!: vorhanden ist, sollte MAJOR erhöht werden. Das Release Please-Plug-in kann sogar eine CHANGELOG-Datei generieren und das Release automatisch taggen.

Erweiterten Bereitstellungsmodus verwenden

Nachdem Änderungen vorgenommen und als Pull-Request in der Entwicklungsinstanz eingereicht wurden, kennzeichnet das Release Please-Plug-in die Änderungen mit einem Versionstag wie v1.2.3. Im erweiterten Bereitstellungsmodus von Looker werden diese Versionen dann in der Looker-Benutzeroberfläche für die QA- und Produktionsinstanzen verfügbar gemacht.

So stellen Sie eine Änderung bereit:

Speicherort von Looker Deployment Manager in der IDE.

Klicken Sie rechts oben im Deployment Manager auf den Link Commit auswählen. Wählen Sie dann das Dreipunkt-Menü für das Tag aus, das Sie bereitstellen möchten, und wählen Sie In Umgebung bereitstellen aus:

Looker Deployment Manager-Benutzeroberfläche für die Bereitstellung in der Umgebung.

Sie müssen die Bereitstellung nicht noch einmal taggen. Wählen Sie daher Ohne Tagging bereitstellen aus und klicken Sie auf die Schaltfläche In Umgebung bereitstellen:

Looker Deployment Manager-Benutzeroberfläche für die Bereitstellung ohne Tagging.

Stellen Sie die Änderungen schließlich mit dem Deployment Manager in der Produktionsumgebung bereit.

Looker Continuous Integration verwenden

Um Änderungen in einem Entwicklungszweig oder als Teil einer Pull-Anfrage zu überprüfen, können Entwickler Looker Continuous Integration verwenden. Continuous Integration bietet die folgenden Validatoren:

Sie können diese Validatoren in Continuous Integration-Suites gruppieren und sie automatisch bei Pull-Anfragen, nach einem Zeitplan oder manuell ausführen.

SQL-Validator

Mit dem SQL-Validator für Continuous Integration wird geprüft, ob die Dimensionen in Ihren Explores korrekt für Ihre Datenbank ausgeführt werden. Es wird geprüft, ob Felder, die in LookML-Ansichten definiert sind, gültigen SQL-Spalten oder ‑Ausdrücken in der Datenbank entsprechen.

Der SQL-Validator bietet die folgenden Hauptfunktionen:

Weitere Informationen und Konfigurationsoptionen finden Sie auf der Dokumentationsseite Continuous Integration SQL Validator.

LookML-Validator

Der LookML-Validator für die kontinuierliche Integration prüft Ihr LookML-Projekt auf Syntaxfehler wie fehlende Klammern oder ungültige Feldverweise. Dieser Validator ist besonders hilfreich für Entwickler, die LookML außerhalb der Looker IDE schreiben.

Der LookML-Validator bietet die folgenden Hauptfunktionen:

  • Hiermit können Sie einen Schweregradschwellenwert (Fehler, Warnung oder Information) festlegen, der bestimmt, bei welchem Schweregrad eine Ausführung fehlschlägt.
  • Ermöglicht es Ihnen, eine Zeitüberschreitung für Validierungsläufe zu konfigurieren.

Weitere Informationen und Konfigurationsoptionen finden Sie auf der Dokumentationsseite LookML-Validator für die kontinuierliche Integration.

Inhaltsvalidierung

Mit der Inhaltsvalidierung für die kontinuierliche Integration wird geprüft, ob gespeicherte Inhalte wie Looks und benutzerdefinierte Dashboards nach LookML-Änderungen weiterhin ordnungsgemäß funktionieren.

Die Inhaltsvalidierung bietet die folgenden Hauptfunktionen:

Weitere Informationen und Konfigurationsoptionen finden Sie auf der Dokumentationsseite Continuous Integration Inhaltsvalidierung.

Assert-Validator

Der Continuous Integration Assert Validator führt LookML-Datentests aus, die in Ihrem Projekt definiert sind, um die Modelllogik und Datenintegrität zu prüfen.

Ein LookML-Datentest könnte beispielsweise so aussehen:

test: historic_revenue_is_accurate {
  explore_source: orders {
    column: total_revenue { field: orders.total_revenue }
    filters: [orders.created_date: "2024"]
  }
  assert: revenue_is_expected_value {
    expression: ${orders.total_revenue} = 626000 ;;
  }
}

Der Assert Validator bietet die folgenden wichtigen Funktionen:

Weitere Informationen und Konfigurationsoptionen finden Sie auf der Dokumentationsseite Continuous Integration Assert Validator.

CI-Suites verwalten und ausführen

So verwalten und führen Sie Continuous Integration-Tests aus:

Standardmäßig erhalten Looks und Dashboards aufsteigende numerische IDs, die in der URL für den Look oder das Dashboard verwendet werden. Es gibt jedoch keine Möglichkeit, diese systemübergreifend zu synchronisieren. Daher verweist eine URL für ein bestimmtes Dashboard in der Entwicklung nicht auf dasselbe Dashboard in der Qualitätssicherung oder Produktion.

Bei benutzerdefinierten Dimensionen und Messwerten kann anstelle einer ID ein Slug als Teil der URL verwendet werden. Der Slug ist eine halb zufällige Zeichenfolge und keine Zahl. Der Slug kann im Rahmen des Imports festgelegt werden, sodass eine ähnliche URL in der Entwicklung, Qualitätssicherung und Produktion auf dieselbe UDD verweisen kann. Die Verwendung von Kurzbezeichnungen anstelle von IDs ist eine Best Practice, insbesondere wenn Sie von einem Look oder einer anderen benutzerdefinierten Dimension auf eine benutzerdefinierte Dimension klicken.

Den Slug finden Sie, indem Sie die Ausgabe von gzr dashboard cat untersuchen. Der Alias kann in der Dashboard-URL anstelle der numerischen ID verwendet werden.

Nutzerinhalte mit Gazer migrieren

Das Kopieren von Inhalten wie Looks und Dashboards zwischen Entwicklung, Qualitätssicherung und Produktion ist oft nützlich. Möglicherweise möchten Sie Inhalte erstellen, in denen neue LookML-Ergänzungen vorgestellt werden, oder überprüfen, ob gespeicherte Inhalte nach LookML-Änderungen weiterhin richtig funktionieren. In diesen Fällen kann Gazer verwendet werden, um Inhalte zwischen Instanzen zu kopieren.

LookML-Dashboards

LookML-Dashboards werden während des regulären LookML-CI/CD-Workflows zwischen Instanzen synchronisiert. Wenn jedoch UDDs mit LookML-Dashboards synchronisiert werden, können sie mit Gazer mit dem folgenden Befehl aktualisiert werden:

gzr dashboard sync_lookml DASHBOARD_ID --host TARGET_SYSTEM_URL

Benutzerdefinierte Dashboards

Benutzerdefinierte Dashboards können mit Gazer migriert werden, indem auf die ID des Dashboards und die URL der Looker-Instanz verwiesen wird, in der sich das benutzerdefinierte Dashboard befindet. Gazer speichert die Dashboard-Konfiguration in einer JSON-Datei, die dann in die Ziel-Looker-Instanz importiert wird.

Der Befehl zum Extrahieren der UDD-Konfiguration lautet so:

gzr dashboard cat DASHBOARD_ID --host TARGET_SYSTEM_URL --dir .

Dadurch wird eine Datei mit dem Namen Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json generiert, die die Konfiguration des Dashboards enthält.

Die UDD kann mit dem folgenden Befehl in das Zielsystem importiert werden:

gzr dashboard import Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json FOLDER_ID \
    --host TARGET_SYSTEM_URL

Looks

Die Look-Migration funktioniert sehr ähnlich wie die Migration von benutzerdefinierten Daten. Speichern Sie zuerst die Look-Konfiguration mit Gazer in einer JSON-Datei:

gzr look cat LOOK_ID --host SOURCE_SYSTEM_URL --dir .

Importieren Sie den Look dann in die Zielinstanz:

gzr look import Look_LOOK_ID_LOOK_NAME.json FOLDER_ID \
    --host TARGET_SYSTEM_URL