Beachten Sie, dass Sie sich gerade die Looker-Dokumentation ansehen. Die Looker Studio-Dokumentation finden Sie unter https://support.google.com/looker-studio.

Diese Seite wurde von der Cloud Translation API übersetzt.

Nutzung und Workflow von Looker CI/CD

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

Diese Anweisungen basieren auf einem dreistufigen System, das aus Entwicklung, QA und Produktion besteht. Dieselben Prinzipien können jedoch auch auf ein zweistufiges oder vierstufiges System angewendet werden.

In dieser Anleitung wird außerdem 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 nötige Fachwissen verfügen, um diese Anweisungen für Ihren Anbieter zu ändern.

Workflowübersicht

LookML-Entwickler beginnen damit, Code in ihrem Entwicklungszweig zu schreiben, der normalerweise so etwas wie dev-my-user-ydnv heißt. Anschließend testen sie ihre Änderungen mit Spectacles und committen den Code. Schließlich öffnet er eine Pull-Anfrage, um seinen Code mit dem main-Zweig zusammenzuführen.

Wenn der Pull-Request geöffnet wird, wird der Entwickler zu GitHub weitergeleitet. Der Entwickler sollte einen aussagekräftigen PR-Titel im konventionellen Commit-Stil verfassen und der Beschreibung einen Kommentar hinzufügen, der in das Änderungsprotokoll aufgenommen wird. Die Ergebnisse der Spectacles-Tests sollten der PR als Kommentare hinzugefügt werden.

Als Nächstes sollte der Entwickler einen Prüfer in GitHub auswählen. Der Prüfer wird benachrichtigt und kann seine Rezension der PR hinzufügen. Wenn der Prüfer die Änderung genehmigt, wird PR mit dem Zweig main zusammengeführt. Ein Webhook wird aufgerufen und die Änderung wird jetzt in der Entwicklungsumgebung angezeigt.

Die Release Please-Automatisierung wird automatisch ausgeführt und eine zweite PR wird geöffnet, um einen neuen getaggten Release zu erstellen. Wenn bereits eine Pull-Anfrage für diesen Zweck vorhanden ist, aktualisiert Release Please diese. Dem Release-PR ist eine Versionsnummer sowie ein Änderungsprotokoll mit den Titeln und Beschreibungen der enthaltenen Änderungen zugeordnet.

Wenn die vom Release bitte generierte PR genehmigt und zusammengeführt wurde, wird ein neues Versions-Tag generiert und das Änderungsprotokoll mit dem main-Zweig zusammengeführt. Die QA- und Produktionsinstanzen von Looker können diese Version über den 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 so benannt und nummeriert werden, wie es für Ihre Umgebung sinnvoll ist. Hier wird jedoch semantische Versionsverwaltung verwendet, was wir sehr empfehlen, 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 einem Release ein Fehler behoben wird
MINOR wird jedes Mal erhöht und PATCH wird auf null gesetzt, wenn in einem Release eine Funktion hinzugefügt oder optimiert wird, die abwärtskompatibel ist
MAJOR wird erhöht und sowohl MINOR als auch PATCH werden auf null gesetzt, wenn eine Funktion hinzugefügt wird, die nicht abwärtskompatibel ist.

Konventionelle Commits sind ein System, bei dem Commits nach ihrer Auswirkung auf die Endnutzer benannt werden. Die Verwendung der konventionellen Commit-Benennung ist zwar nicht erforderlich, aber auch für das Release Bitte-Plug-in hilfreich.

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

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

Wenn herkömmliche Commits konsistent verwendet werden, ist es im Allgemeinen unkompliziert, die als Nächstes zu verwendende semantische Zahl zu bestimmen. Wenn das Commit-Log nur aus fix:- und doc:-Commits besteht, sollte PATCH erhöht werden. Wenn es einen feat:-Commit gibt, sollte MINOR erhöht werden. Wenn ein feat!: vorhanden ist, sollte MAJOR erhöht werden. Das Release Please-Plug-in kann sogar eine CHANGELOG-Datei generieren und die Version automatisch taggen.

Erweiterten Bereitstellungsmodus verwenden

Nachdem Änderungen vorgenommen und als PR in der Entwicklungsinstanz eingereicht wurden, taggt das Release Bitte-Plug-in die Änderungen mit einem Versions-Tag wie v1.2.3. Mit dem erweiterten Bereitstellungsmodus von Looker werden diese Versionen dann in der Looker-Benutzeroberfläche für die Qualitätssicherungs- und Produktionsinstanzen verfügbar.

Wenn Sie eine Änderung bereitstellen möchten, wählen Sie in der Looker IDE den Deployment Manager aus:

Speicherort des Looker Deployment Managers in der IDE.

Klicken Sie rechts oben im Deployment Manager auf den Link Select Commit (Commit auswählen). Klicken Sie dann auf das Dreipunkt-Menü, das mit dem Tag verknüpft ist, das Sie bereitstellen möchten, und wählen Sie In Umgebung bereitstellen aus:

Looker Deployment Manager-Benutzeroberfläche zur Bereitstellung in der Umgebung

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

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

Schließlich übertragen Sie mit Deployment Manager per Push in die Produktion.

Spectacles verwenden

Spectacles kann von jedem Entwickler verwendet werden, um seine Änderungen zu überprüfen, während sie sich noch in seinem Entwicklungszweig befinden. Spectacles bietet vier verschiedene Validatoren:

SQL
LookML
Inhalt
Bestätigen

Wenn ein Entwickler einen Pull-Request einreicht, empfiehlt es sich, diese Tests auszuführen und die Ergebnisse in einen Kommentar im PR zu kopieren.

SQL-Validator

Der SQL-Validator prüft jedes Explore, um sicherzustellen, dass alle in LookML-Ansichten definierten Felder tatsächlichen SQL-Spalten oder gültigen SQL-Ausdrücken in der Datenbank entsprechen. Der SQL-Validator wird so aufgerufen:

$ spectacles sql --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

Beispiel:

$ spectacles sql --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0

=================== Testing 1/1 explores [concurrency = 10] ===================

✓ thelook_cicd.users passed

Completed SQL validation in 1 minute and 7 seconds.

LookML Validator

Der LookML Validator stellt sicher, dass LookML-Änderungen gültig sind und keine Syntaxfehler enthalten. So wird es aufgerufen:

$ spectacles lookml --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --branch DEV_BRANCH_NAME

Beispiel:

$ spectacles lookml --config-file config-dev.yaml \
    --project thelook_cicd \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0

============= Validating LookML in project thelook_cicd [warning] ==============

✗ thelook_cicd/business_pulse.dashboard.lookml failed
✗ thelook_cicd/thelook_cicd.model.lkml failed

================ thelook_cicd/business_pulse.dashboard.lookml:28 ===============

[Error] Unknown field "users.state" in explore "users" for field_filter.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/business_pulse.dashboard.lookml?line=28

================ thelook_cicd/business_pulse.dashboard.lookml:36 ===============

[Warning] Unknown field "users.state" (for explore "orders" in model
"thelook_cicd") referenced in dashboard element.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/business_pulse.dashboard.lookml?line=36

[Additional errors snipped]

Completed validation in 6 seconds.

Inhaltsvalidierung

Der Content Validator prüft, ob gespeicherte Inhalte wie Looks und benutzerdefinierte Dashboards (User-Defined Dashboards, UDFs) auch nach Änderungen funktionieren. Damit der Job schneller ausgeführt wird und überschaubare Ergebnisse liefert, wird die Validierung nur für Inhalte durchgeführt, die auf von Ihnen angegebenen explorativen Datenanalysen basieren. Der Inhaltsvalidator wird so aufgerufen:

$ spectacles content --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

Beispiel:

$ spectacles content --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0
Building LookML project hierarchy for project 'thelook_cicd' @ dev-my-user-ydnv

==================== Validating content based on 5 explores ====================

✗ thelook_cicd.users failed

================= test dashboard for spectacles [TheLook_CICD] =================

Tile 'test dashboard for spectacles' failed validation.

Error in thelook_cicd/users: Unknown field "users.state".

Dashboard: https://gcpl2318.cloud.looker.com/dashboards/223

========================= Business Pulse [TheLook_CICD] ========================

Filter 'State / Region' failed validation.

Error in thelook_cicd/users: Unknown field "users.state".

Dashboard: https://gcpl2318.cloud.looker.com/dashboards/190

Completed content validation in 27 seconds.

Bestätigung bestätigen

Bei der Validierung von Behauptungen werden Datenbehauptungen geprüft, die Sie Ihrer LookML hinzugefügt haben, um sicherzustellen, dass die Daten richtig gelesen werden. Ein Datentest in Ihrer LookML könnte beispielsweise so aussehen:

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

Die Assertion-Validierung wird wie folgt aufgerufen:

$ spectacles assert --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

Beispiel:

$ spectacles assert --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0
Building LookML project hierarchy for project 'thelook_cicd' @ dev-my-user-ydnv

==================== Running data tests based on 1 explore =====================

✗ thelook_cicd.users failed

================ thelook_cicd/users/california_users_is_accurate ===============

Unknown filter field "users.state" in lookml test "california_users_is_accurate"
declaration.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

================ thelook_cicd/users/california_users_is_accurate ===============

Invalid filter: users.state

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

================ thelook_cicd/users/california_users_is_accurate ===============

Assertion "count_is_expected_value" failed: expression evaluated to "No".

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

Completed data test validation in 14 seconds.

Stabilität der Verknüpfung von Looks und Dashboards

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 zwischen Systemen zu synchronisieren. Daher verweist eine URL für ein bestimmtes Dashboard in der Entwicklung nicht auf dasselbe Dashboard in der QA oder Produktion.

Bei UDDs kann anstelle einer ID ein Slug als Teil der URL verwendet werden. Der Slug besteht aus einer semi-zufälligen Zeichenfolge und nicht aus einer Zahl. Der Slug kann beim Import festgelegt werden, sodass eine ähnliche URL auf dieselbe UDD für Entwicklung, QA und Produktion verweisen kann. Es empfiehlt sich, Slug-IDs anstelle von IDs zu verwenden, insbesondere wenn Sie von einem Look oder einer anderen UDD zu einer UDD „durchklicken“.

Sie finden den Slug in der Ausgabe von gzr dashboard cat. Der Slug kann anstelle der numerischen ID in der Dashboard-URL verwendet werden.

Nutzerinhalte mit Gazer migrieren

Das Kopieren von Inhalten wie Looks und Dashboards zwischen Entwicklung, QA und Produktion ist oft nützlich. Sie können Inhalte erstellen, in denen neue LookML-Ergänzungen präsentiert werden, oder dafür sorgen, dass 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 UDDs jedoch mit LookML-Dashboards synchronisiert sind, können sie mit dem folgenden Befehl mit Gazer aktualisiert werden:

gzr dashboard sync_lookml DASHBOARD_ID --host TARGET_SYSTEM_URL

Benutzerdefinierte Dashboards

Benutzerdefinierte Dashboards (UDDs) können mit Gazer migriert werden, indem auf die ID des Dashboards und die URL der Looker-Instanz verwiesen wird, in der sich die UDD 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 wie folgt:

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 UDD-Migration. 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