Diese Seite wurde von der Cloud Translation API übersetzt.

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 Entwicklung, QA und Produktion umfasst. 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 auch andere Git-Anbieter verwenden, um einen CI/CD-Workflow zu erstellen. Sie müssen jedoch die erforderlichen Kenntnisse haben, um diese Anleitung für Ihren Anbieter anzupassen.

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 herkömmlichen Commit-Stil verfassen und der Beschreibung einen Kommentar hinzufügen, der in den Änderungslog aufgenommen wird. Die Ergebnisse der Spectacles-Tests sollten dem 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 die PR mit dem main-Zweig 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 geöffnet ist, aktualisiert Release Please diese Pull-Anfrage. Dem Release-PR ist eine Versionsnummer und ein Änderungslog mit den Titeln und Beschreibungen der enthaltenen Änderungen zugeordnet.

Wenn der von Release Please generierte PR genehmigt und zusammengeführt wird, wird ein neues Versions-Tag generiert und der Änderungslog wird mit dem main-Zweig zusammengeführt. Diese Version kann für die QA- und Produktionsinstanzen von Looker über den erweiterten Bereitstellungsmodus ausgewählt werden.

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

Die Releases und die zugehörigen Tags können in Ihrer Umgebung beliebig benannt und nummeriert werden. Hier wird jedoch semantische Versionsverwaltung verwendet, was wir sehr empfehlen, da es gut mit dem Release Please-Plug-in funktioniert.

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

PATCH wird jedes Mal erhöht, wenn mit einem Release ein Fehler behoben wird.
MINOR wird jedes Mal erhöht und PATCH auf null zurückgesetzt, wenn der Release eine Funktion hinzufügt oder optimiert, 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 ist ein System, mit dem Commits anhand ihrer Auswirkungen auf Endnutzer benannt werden. Die Verwendung herkömmlicher Commit-Namen ist zwar nicht erforderlich, aber auch für das Release Please-Plug-in nützlich.

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 die Dokumente aktualisiert, aber LookML nicht geändert wird, beginnt die Commit-Nachricht mit doc:.

Wenn konventionelle Commits konsequent verwendet werden, ist es in der Regel ganz einfach, die nächste 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 die Änderungen vorgenommen und als PR in der Entwicklungsinstanz eingereicht wurden, werden sie vom Release Please-Plug-in mit einem Versions-Tag wie v1.2.3 getaggt. Über den erweiterten Bereitstellungsmodus von Looker werden diese Versionen dann in der Looker-Benutzeroberfläche für die QA- und Produktionsinstanzen verfügbar gemacht.

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 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 für die 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

Führen Sie abschließend mit Deployment Manager die Bereitstellung in der Produktion durch.

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 Validator:

SQL
LookML
Inhalt
Assert

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 sorgt dafür, dass LookML-Änderungen gültig sind und keine Syntaxfehler enthalten. Sie wird so 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 dem Inhaltsvalidierer wird geprüft, ob gespeicherte Inhalte wie Looks und benutzerdefinierte Dashboards (UDDs) nach Änderungen noch 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.

Assert-Validierung

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 Assert-Validierung wird wie unten dargestellt 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 Entwicklungsphase nicht auf dasselbe Dashboard in der QA oder Produktion.

Für 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 im Rahmen des Imports festgelegt werden, damit eine ähnliche URL in der Entwicklung, im QA-Prozess und in der Produktion auf dieselbe UDD verweist. Es empfiehlt sich, Slug-IDs anstelle von IDs zu verwenden, insbesondere wenn Sie von einem Look oder einer anderen UDD zu einer UDD „durchklicken“.

Den Slug findest du in der Ausgabe von gzr dashboard cat. Der Slug kann anstelle der numerischen ID in der Dashboard-URL verwendet werden.

Nutzerinhalte mit Gazer migrieren

Es ist oft nützlich, Inhalte wie Looks und Dashboards zwischen der Entwicklungs-, QA- und Produktionsumgebung zu kopieren. 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 ordnungsgemäß 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 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 erstellt, 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 dann den Look in die Zielinstanz:

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