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

Nutzung und Workflow von Looker CI/CD

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

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

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

Workflowübersicht

LookML-Entwickler schreiben zuerst Code in ihren Entwicklungszweig, der normalerweise einen Namen wie dev-my-user-ydnv hat, testen ihre Änderungen mit Spectacles und führen einen Commit für ihren Code durch. Schließlich öffnet sie eine Pull-Anfrage, um ihren Code mit dem main-Zweig zusammenzuführen.

Wenn die Pull-Anfrage geöffnet wird, wird der Entwickler zu GitHub weitergeleitet. Der Entwickler sollte einen aussagekräftigen PR-Titel im üblichen Commit-Stil verfassen und der Beschreibung, die im Änderungsprotokoll enthalten ist, einen Kommentar hinzufügen. Die Ergebnisse der Spectacles-Tests sollten dem PR-Team als Kommentare hinzugefügt werden.

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

Die Automatisierung für „Release Bitte“ wird automatisch ausgeführt und ein zweiter PR-Code wird geöffnet, um einen neuen getaggten Release zu erstellen. Wenn für diesen Zweck bereits eine PR-Abteilung offen ist, aktualisieren Sie diese bitte. Der Release-PR ist eine Versionsnummer sowie ein Änderungsprotokoll mit den Titeln und Beschreibungen der enthaltenen Änderungen zugeordnet.

Wenn die PR-Datei, die vom Release bitte generiert wurde, 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 kann diese Version mit dem erweiterten Bereitstellungsmodus auswählen.

Best Practices zum Nummerieren von Releases und zum Benennen von Commits

Die Releases und die zugehörigen Tags können so benannt und nummeriert werden, wie es für Ihre Umgebung sinnvoll ist. Allerdings wird hier die semantische Versionsverwaltung verwendet. Diese Version wird dringend empfohlen, da sie gut mit dem Release-Bitte-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 ein Release einen Fehler behebt
MINOR wird erhöht und PATCH wird jedes Mal auf null zurückgesetzt, wenn der Release eine Funktion hinzufügt oder optimiert, die abwärtskompatibel ist
MAJOR wird erhöht und MINOR und PATCH werden auf null gesetzt, wenn ein Feature hinzugefügt wird, das nicht abwärtskompatibel ist.

Konventionelle Commits sind ein System, bei dem Commits nach ihrer Auswirkung auf Endnutzer benannt werden. Die Verwendung einer herkömmlichen Commit-Benennung ist zwar nicht erforderlich, aber auch für das Plug-in "Release Bitte" nützlich.

Bei der herkömmlichen Commit-Benennung wird jeder Commit-Nachricht ein Indikator des Umfangs der Änderung vorangestellt:

Mit fix: wird eine Fehlerkorrektur angezeigt, z. B. fix: set proper currency symbol on sale_amt format.
Ein neues Element wird mit feat: gekennzeichnet, z. B. feat: added explore for sales by territory.
Ein Element mit einer funktionsgefährdenden Änderung wird durch feat!: wie feat!: rewrote sales explore to use the new calendar view gekennzeichnet.
Wenn Dokumente aktualisiert, LookML aber nicht geändert wird, beginnt die Commit-Nachricht mit doc:

Wenn konventionelle Commits konsistent verwendet werden, ist die Bestimmung der als Nächstes zu verwendenden semantischen Zahl im Allgemeinen einfach. Wenn das Commit-Log nur aus Commits vom Typ fix: und doc: besteht, muss PATCH erhöht werden. Bei einem feat:-Commit sollte MINOR erhöht werden. Wenn feat!: vorhanden ist, sollte MAJOR erhöht werden. Das Release Bitte-Plug-in kann sogar eine CHANGELOG-Datei generieren und den Release automatisch taggen.

Erweiterter Bereitstellungsmodus verwenden

Nachdem Änderungen vorgenommen und als PR auf der Entwicklungsinstanz eingereicht wurden, kennzeichnet das Release Bitte-Plug-in die Änderungen mit einem Versions-Tag wie v1.2.3. Der erweiterte Bereitstellungsmodus von Looker stellt diese Versionen dann in der Looker-Benutzeroberfläche für QA- und Produktionsinstanzen zur Verfügung.

Wählen Sie zum Bereitstellen einer Änderung in der Looker-IDE den Deployment Manager aus:

Speicherort von Looker Deployment Manager in der IDE.

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

Looker Deployment Manager-UI 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-UI für die Bereitstellung ohne Tagging

Übertragen Sie schließlich mithilfe von Deployment Manager einen Push in die Produktion.

Spectacles verwenden

Mit Spectacles kann jeder Entwickler seine Änderungen prüfen, während sie sich noch im Entwicklungszweig befinden. Spectacles bietet vier verschiedene Validatoren:

SQL
LookML
Content
Bestätigen

Wenn ein Entwickler eine Pull-Anfrage sendet, empfiehlt es sich, diese Tests durchzuführen und die Ergebnisse in einen Kommentar im PR zu kopieren.

SQL-Validator

Der SQL Validator testet jeden Explore, um sicherzustellen, dass alle in LookML-Ansichten definierten Felder den tatsächlichen SQL-Spalten oder gültigen SQL-Ausdrücken in der Datenbank entsprechen. Der SQL Validator wird wie folgt 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. Sie wird wie folgt 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 testet, ob gespeicherte Inhalte wie Looks und benutzerdefinierte Dashboards (UDDs) auch nach Vornahme von Änderungen funktionieren. Um den Job schneller auszuführen und überschaubare Ergebnisse zu liefern, erfolgt die Validierung nur für Inhalte, die auf von Ihnen angegebenen Explores basieren. Der Name des Content Validators sieht so aus:

$ 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.

Validierung bestätigen

Assert Validation testet Daten-Assertions, die Sie Ihrem LookML-Code hinzugefügt haben, um sicherzustellen, dass die Daten richtig gelesen werden. Ein Datentest in Ihrem LookML-Code 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 Assert-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.

Linkstabilität für 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 systemübergreifend zu synchronisieren. Daher verweist eine URL für ein bestimmtes in der Entwicklung befindliches Dashboard nicht auf dasselbe Dashboard in QA oder Produktion.

Für UDDs gibt es eine Option, um einen Slug anstelle einer ID als Teil der URL zu verwenden. Ein Slug ist eine halbzufällige Gruppe von Zeichen und keine Zahl. Der Slug kann als Teil des Imports festgelegt werden, sodass eine ähnliche URL bei Entwicklung, QA und Produktion auf dasselbe UDD verweisen kann. Die Verwendung von Slugs anstelle von IDs hat sich bewährt, insbesondere wenn ein Click-through zu einem UDD von einem Look oder einem anderen UDD erfolgt.

Den Slug finden Sie in der Ausgabe von gzr dashboard cat. Der Slug 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, QA und Produktion ist oft nützlich. Möglicherweise möchten Sie Inhalte erstellen, in denen neue LookML-Ergänzungen vorgestellt werden, oder sicherstellen, dass gespeicherte Inhalte nach LookML-Änderungen weiterhin korrekt 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 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 (UDDs) können mit Gazer migriert werden, indem Sie auf die Dashboard-ID und die URL der Looker-Instanz verweisen, auf der sich der UDD befindet. Gazer speichert die Dashboard-Konfiguration in einer JSON-Datei, die dann in die Looker-Zielinstanz importiert wird.

Der Befehl zum Extrahieren der UDD-Konfiguration lautet:

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.

Das 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 mit Gazer die Look-Konfiguration in einer JSON-Datei:

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

Importieren Sie dann den Look in die Zielinstanz:

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