Looker-CI/CD-Nutzung und -Workflow

Auf dieser Seite wird erläutert, wie Sie einen 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 dieselben 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 anzupassen.

Workflowübersicht

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

Wenn die Pull-Anfrage geöffnet wird, wird der Entwickler zu GitHub weitergeleitet. Der Entwickler sollte einen aussagekräftigen Titel für die Pull-Anfrage im Stil von Conventional Commits schreiben und einen Kommentar zur Beschreibung hinzufügen, der im Änderungsprotokoll enthalten sein soll. Die Ergebnisse der Spectacles-Tests sollten als Kommentare zur Pull-Anfrage hinzugefügt werden.

Als Nächstes sollte der Entwickler in GitHub einen Prüfer auswählen. Der Prüfer erhält eine Benachrichtigung und kann seine Überprüfung zur Pull-Anfrage hinzufügen. Wenn der Prüfer die Änderung genehmigt, wird die Pull-Anfrage mit dem Zweig main zusammengeführt. Ein WebHook wird aufgerufen und die Entwicklungs-Umgebung sieht jetzt die Änderung.

Automatisch wird die Release Please-Automatisierung ausgeführt und eine zweite Pull-Anfrage geöffnet, um eine neue getaggte Version zu erstellen. Wenn bereits eine Pull-Anfrage für diesen Zweck geöffnet ist, wird diese von Release Please aktualisiert. Die Release-Pull-Anfrage hat eine Versionsnummer sowie ein Änderungsprotokoll mit den Titeln und Beschreibungen der enthaltenen Änderungen.

Wenn die von Release Please generierte Pull-Anfrage genehmigt und zusammengeführt wird, wird ein neues Versionstag generiert und das Änderungsprotokoll mit dem Zweig main zusammengeführt. Die Qualitätssicherungs- und Produktionsinstanzen von Looker können diese Version im 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 die semantische Versionierung verwendet, die sehr empfehlenswert ist, da sie gut mit dem Release Please-Plug-in funktioniert.

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

  • PATCH wird jedes Mal erhöht, wenn ein Fehler in einem Release behoben wird.
  • MINOR wird erhöht und PATCH wird auf null zurückgesetzt, wenn dem Release eine Funktion hinzugefügt oder eine Funktion verbessert wird, während die Abwärtskompatibilität erhalten bleibt.
  • 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.

Conventional Commits ist ein System zur Benennung von Commits nach ihren Auswirkungen auf Endnutzer. Die Verwendung von Conventional Commits ist zwar nicht erforderlich, aber auch für das Release Please-Plug-in nützlich.

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

  • Ein Fehlerbehebung wird mit fix: angegeben, z. B. fix: set proper currency symbol on sale_amt format
  • Eine neue Funktion wird mit feat: angegeben, z. B. feat: added explore for sales by territory.
  • Eine Funktion mit einer Breaking Change wird mit feat!: angegeben, z. B. feat!: rewrote sales explore to use the new calendar view
  • Wenn die Dokumentation aktualisiert, LookML aber 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 zu verwendende semantische Nummer zu bestimmen. Wenn das Commit-Protokoll nur aus fix:- und doc:-Commits besteht, sollte PATCH erhöht werden. Wenn ein feat:-Commit vorhanden ist, sollte MINOR erhöht werden. Wenn ein feat!:-Commit 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-Anfrage in der Entwicklungsinstanz eingereicht wurden, taggt das Release Please-Plug-in die Änderungen mit einem Versionstag wie v1.2.3. Im erweiterten Bereitstellungsmodus von Looker sind diese Versionen dann in der Looker-Benutzeroberfläche für die Qualitätssicherungs- und Produktionsinstanzen verfügbar.

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

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ü aus, 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 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 die Änderungen schließlich mit dem Deployment Manager in die Produktionsumgebung.

Spectacles verwenden

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

Wenn ein Entwickler eine Pull-Anfrage einreicht, ist es empfehlenswert, diese Tests auszuführen und die Ergebnisse in einen Kommentar in der Pull-Anfrage zu kopieren.

SQL-Validator

Der SQL-Validator testet jedes Explore, um zu prüfen, ob alle in LookML-Ansichten definierten Felder tatsächlichen SQL-Spalten oder gültigen SQL-Ausdrücken in der Datenbank entsprechen. Der SQL-Validator wird wie unten gezeigt 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 prüft, ob LookML-Änderungen gültig sind und keine Syntaxfehler enthalten. Er wird wie unten gezeigt 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

Mit der Inhaltsvalidierung wird geprüft, ob gespeicherte Inhalte wie Looks und nutzerdefinierte Dashboards (UDDs) nach Änderungen weiterhin funktionieren. Damit der Job schneller ausgeführt wird und überschaubare Ergebnisse liefert, erfolgt die Validierung nur für Inhalte, die auf von Ihnen angegebenen Explores basieren. Die Inhaltsvalidierung 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.

Assert-Validierung

Mit der Assert-Validierung werden Datenassertions getestet, die Sie Ihrem LookML hinzugefügt haben, um zu prüfen, ob Daten richtig gelesen werden. Ein Datentest in Ihrem 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 Assert-Validierung wird wie unten gezeigt 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.

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 über mehrere Systeme hinweg zu synchronisieren. Daher verweist eine URL für ein bestimmtes Dashboard in der Entwicklung nicht auf dasselbe Dashboard in der Qualitätssicherung oder Produktion.

Für UDDs gibt es die Möglichkeit, anstelle einer ID einen Slug als Teil der URL zu verwenden. Der Slug ist eine halb zufällige Zeichenfolge und keine Zahl. Der Slug kann im Rahmen des Imports festgelegt werden, sodass eine ähnliche URL auf dasselbe UDD in der Entwicklung, Qualitätssicherung und Produktion verweisen kann. Die Verwendung von Slugs anstelle von IDs ist eine Best Practice, insbesondere wenn Sie von einem Look oder einem anderen UDD zu einem UDD wechseln.

Der Slug kann durch Überprüfen der Ausgabe von gzr dashboard cat gefunden werden. Der Slug kann in der Dashboard-URL anstelle der numerischen ID verwendet werden.

Nutzerinhalte mit Gazer migrieren

Es ist oft nützlich, Inhalte wie Looks und Dashboards zwischen der Entwicklung, Qualitätssicherung und Produktion zu kopieren. Möglicherweise möchten Sie Inhalte erstellen, die neue LookML-Ergänzungen präsentieren, oder prüfen, ob 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 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

Nutzerdefinierte Dashboards

Nutzerdefinierte Dashboards (UDDs) können mit Gazer migriert werden, indem Sie auf die ID des Dashboards und die URL der Looker-Instanz verweisen, auf der sich das 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 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.

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 die Look-Konfiguration mit Gazer 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