Auf dieser Seite wird beschrieben, wie Sie die erforderlichen Komponenten installieren und konfigurieren, um einen mehrstufigen CI/CD-Workflow in Looker zu implementieren.
In dieser Anleitung wird ein dreistufiges System verwendet, das aus Entwicklung, Qualitätssicherung und Produktion besteht. Dieselben Prinzipien können jedoch auch auf ein Zwei- oder Vier-Tier-System angewendet werden.
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.
Folgen Sie der Anleitung im für Sie relevanten Abschnitt:
- Voraussetzungen
- Einrichtungsschritte nur beim ersten Mal
- Einrichtungsschritte für jeden Looker-Entwickler
Vorbereitung
Linux-Umgebung
Bei diesem Prozess wird das Tool Gazer verwendet, das für Unix-ähnliche Betriebssysteme entwickelt wurde. Jeder LookML-Entwickler, der Nutzerinhalte migrieren muss, benötigt Zugriff auf die Befehlszeile in einer Linux-Umgebung oder unter macOS, in der Sie Ihren CI/CD-Workflow ausführen möchten.
Wenn Sie Windows verwenden, kann Gazer im Windows-Subsystem für Linux (WSL) von Microsoft verwendet werden. Mit WSL können Sie verschiedene Linux-Distributionen ausführen. Wenn Sie kein bevorzugtes Linux-Betriebssystem haben, ist die aktuelle Version von Ubuntu Linux aufgrund der breiten Unterstützung eine gute Wahl.
In dieser Anleitung finden Sie Beispiele für Linux-Systeme. Wenn Sie macOS oder WSL verwenden, müssen Sie die Anleitung möglicherweise anpassen.
Eine Looker-Instanz pro Stufe
Um diese Konfiguration zu aktivieren, benötigen Sie eine Looker-Instanz für jede Ebene Ihres Systems. Für ein System mit einer Entwicklungs-, einer QA- und einer Produktionsphase sind beispielsweise drei separate Instanzen erforderlich. Die Instanzen können von Google oder vom Kunden gehostet werden.
Identische Verbindungsnamen
Datenbankverbindungen sollten in jeder Looker-Instanz denselben Namen haben, unabhängig davon, welche Ebene sie darstellen. Eine sales-Verbindung sollte beispielsweise in allen Instanzen diesen Namen haben und nicht sales_dev oder sales_qa.
Die Verbindungen können auf dieselbe oder auf verschiedene Datenbanken verweisen. Wenn sie jedoch auf dieselbe Datenbank verweisen, sollten sie unterschiedliche Scratch-Schemas haben, damit sich persistente abgeleitete Tabellen in der Entwicklungs- oder QA-Instanz nicht auf die Produktion auswirken.
Wenn beispielsweise dieselbe Datenbank für alle drei Instanzen verwendet wird, können sie so konfiguriert werden:
| Produktion | QA | Entwicklung | |
| Verbindungsname | sales |
sales |
sales |
| Datenbank | sales_db |
sales_db |
sales_db |
| Scratch-Schema | prod_sales_scratch |
qa_sales_scratch |
dev_sales_scratch |
Wenn für alle drei Instanzen eine eindeutige Datenbank verwendet wird, kann sie so konfiguriert werden:
| Produktion | QA | Entwicklung | |
| Verbindungsname | sales |
sales |
sales |
| Datenbank | sales_db_prod |
sales_db_qa |
sales_db_dev |
| Scratch-Schema | sales_scratch |
sales_scratch |
sales_scratch |
Git-Repository
Für jedes Projekt wird in allen drei Stufen ein einzelnes Git-Repository verwendet. In der Entwicklungsinstanz wird der main-Branch verfolgt, während die QA- und Produktionsinstanzen in der Regel auf Git-Tags verweisen (die später genauer beschrieben werden).
Einrichtungsschritte, die nur beim ersten Mal ausgeführt werden müssen
Die Schritte in diesem Abschnitt müssen nur einmal von einer Person mit Looker-Administratorberechtigungen und Administratorberechtigungen für den Git-Anbieter ausgeführt werden.
Git-Anmeldedaten
Die Linux-Umgebung jedes Entwicklers muss mit demselben Repository verbunden sein, das Sie zum Verwalten Ihrer LookML verwenden. Dabei handelt es sich wahrscheinlich um ein externes Repository, das in einem Dienst wie GitHub gehostet wird. Sie benötigen ein Konto bei diesem Dienst mit den entsprechenden Anmeldedaten, um das Repository zu konfigurieren. Mit dem Konto können Sie einen SSH-Schlüssel einrichten, damit Ihre Linux-Umgebung automatisch eine Verbindung zu diesem Dienst herstellen kann.
Folgen Sie für GitHub der Anleitung unter Einen neuen SSH-Schlüssel zu Ihrem GitHub-Konto hinzufügen.
Git-Server-Repository erstellen und konfigurieren
Damit der CI/CD-Workflow funktioniert, muss LookML in einem Git-Repository gespeichert und mit einem Looker-Projekt verbunden sein. In den Projekteinstellungen muss Git Production Branch Name auf main festgelegt und Enable Advanced Deploy Mode aktiviert sein.
Wenn die folgenden Schritte noch nicht ausgeführt wurden, folgen Sie dieser Anleitung für GitHub:
Neues Repository erstellen
- Klicken Sie in der GitHub-Benutzeroberfläche rechts oben auf das + und wählen Sie Neues Repository aus.
- Wählen Sie den Inhaber aus (wahrscheinlich Ihre Organisation) und geben Sie eine REPOSITORY_NAME ein.
- Wählen Sie aus, ob das Repository öffentlich oder privat sein soll (für private Repositories ist ein kostenpflichtiges GitHub-Abo erforderlich), und setzen Sie ein Häkchen, um es mit einer README-Datei zu initialisieren.
- Klicken Sie auf die Schaltfläche Repository erstellen.
- Klicken Sie auf den grünen Button mit der Aufschrift <> Code und kopieren Sie die SSH-URL. Die Ausgabe sieht etwa so aus:
git@github.com:org_name/REPOSITORY_NAME.git. - Erstellen Sie in Looker ein neues Projekt.
- Rufen Sie den Entwicklermodus auf, wählen Sie in der Seitenleiste links die Projekteinstellungen aus und klicken Sie dann auf Git konfigurieren.
- Fügen Sie die Repository-URL ein (in diesem Beispiel
git@github.com:org_name/REPOSITORY_NAME.git) und wählen Sie Weiter aus. - Kopieren Sie den Bereitstellungsschlüssel und kehren Sie zur GitHub-Benutzeroberfläche für dieses Repository zurück.
- Wählen Sie Einstellungen und dann Aktionen – Allgemein aus.
- Prüfen Sie unter Workflow permissions (Workflowberechtigungen), ob Allow GitHub Actions to create and approve pull requests (GitHub Actions das Erstellen und Genehmigen von Pull-Anfragen erlauben) aktiviert ist, und klicken Sie auf Save (Speichern).
- Wechseln Sie in den GitHub-Einstellungen zur Seite Deploy keys (Bereitstellungsschlüssel).
- Klicken Sie auf den Button Bereitstellungsschlüssel hinzufügen und fügen Sie den Bereitstellungsschlüssel in das Feld Schlüssel ein.
- Fügen Sie einen Titel wie
Looker-REPOSITORY_NAMEhinzu, aktivieren Sie das Kästchen Schreibzugriff zulassen und klicken Sie auf die Schaltfläche Schlüssel hinzufügen. - Kehren Sie zu Looker zurück und wählen Sie Test and Finalize Setup (Einrichtung testen und abschließen) aus.
- Wählen Sie in der linken Seitenleiste noch einmal die Projekteinstellungen aus. Ändern Sie den Namen des Git-Produktionszweigs in
main. - Wählen Sie Erweiterten Bereitstellungsmodus aktivieren und dann Projektkonfiguration speichern aus.
Unter dem Symbol für die Projekteinstellungen auf der linken Seite sollte ein Bereitstellungssymbol für Deployment Manager angezeigt werden.
Vorhandenes Repository verwenden
- Rufen Sie das GitHub-Repository auf, in dem Ihr LookML gespeichert ist. (Geben Sie hier den Namen Ihres Repositorys ein: REPOSITORY_NAME.)
- Wählen Sie Einstellungen und dann Aktionen – Allgemein aus.
- Prüfen Sie unter Workflow permissions (Workflowberechtigungen), ob Allow GitHub Actions to create and approve pull requests (GitHub Actions das Erstellen und Genehmigen von Pull-Anfragen erlauben) aktiviert ist, und klicken Sie auf Save (Speichern).
- Rufen Sie im GitHub-Repository den Bereich <> Code auf.
- Klicken Sie auf den grünen Button mit der Aufschrift <> Code und kopieren Sie die SSH-URL. Die Ausgabe sieht etwa so aus:
git@github.com:org_name/REPOSITORY_NAME.git. - Erstellen Sie in Looker ein neues Projekt.
- Rufen Sie den Entwicklermodus auf, wählen Sie in der Seitenleiste links die Projekteinstellungen aus und klicken Sie dann auf Git konfigurieren.
- Fügen Sie die Repository-URL ein (in diesem Beispiel
git@github.com:org_name/REPOSITORY_NAME.git) und wählen Sie Weiter aus. - Kopieren Sie den Bereitstellungsschlüssel und kehren Sie zur GitHub-Benutzeroberfläche für dieses Repository zurück.
- Wählen Sie Einstellungen und dann Schlüssel bereitstellen aus.
- Klicken Sie auf den Button Bereitstellungsschlüssel hinzufügen und fügen Sie den Bereitstellungsschlüssel in das Feld Schlüssel ein.
- Fügen Sie einen Titel wie
Looker-REPOSITORY_NAMEhinzu, aktivieren Sie das Kästchen Schreibzugriff zulassen und klicken Sie auf die Schaltfläche Schlüssel hinzufügen. - Kehren Sie zu Looker zurück und wählen Sie Test and Finalize Setup (Einrichtung testen und abschließen) aus.
- Wählen Sie in der linken Seitenleiste noch einmal die Projekteinstellungen aus. Ändern Sie den Namen des Git-Produktionszweigs in
main. - Wählen Sie Erweiterten Bereitstellungsmodus aktivieren und dann Projektkonfiguration speichern aus.
Unter dem Symbol für die Projekteinstellungen auf der linken Seite sollte ein Bereitstellungssymbol für Deployment Manager angezeigt werden.
GitHub Actions erstellen
Es ist sinnvoll, mehrere GitHub-Aktionen zu erstellen, damit bei jeder Änderung an LookML automatisch verschiedene Prüfungen durchgeführt werden. Wenn Sie diese Aktionen hinzufügen möchten, müssen Sie Änderungen an Ihrem Git-Repository in Ihrer Linux-Umgebung vornehmen können. Wenn das noch nicht der Fall ist, folgen Sie der Anleitung unter Git konfigurieren.
Um die GitHub-Aktionen hinzuzufügen, rufen Sie das Verzeichnis Ihres Repositorys in der Linux-Umgebung auf und fügen Sie das Unterverzeichnis .github/workflows hinzu. Nach der Einrichtung können diese Aktionen manuell über die Seite Actions der GitHub-Benutzeroberfläche ausgeführt werden.
Look-At-Me-Sideways (LAMS)
LAMS ist ein Open-Source-Linter, der Ihre LookML auf Fehler und schlechte Praktiken untersucht. Fügen Sie dem Verzeichnis .github/workflows eine Datei mit dem Namen lams.yml mit folgendem Inhalt hinzu:
name: LAMS
on:
pull_request:
branches: [ main ]
push:
workflow_dispatch:
jobs:
lams_job:
runs-on: ubuntu-latest
name: LAMS LookML Linter Job
steps:
- name: Checkout your LookML
uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }}
fetch-depth: 0
- name: Setup Node
uses: actions/setup-node@v1
with:
node-version: '16.x'
- name: Install LAMS
run: npm install -g @looker/look-at-me-sideways@3
- name: Run LAMS
run: lams --reporting=no
Jedes Mal, wenn ein Commit an GitHub übertragen wird oder eine Pull-Anfrage zum Zusammenführen von Code mit dem Branch main geöffnet wird, wird LAMS ausgeführt.
Bitte veröffentlichen
Release Please ist ein Open-Source-Tool, mit dem Releases automatisch mit den richtigen Versionsnummern getaggt werden.
Fügen Sie dem Verzeichnis .github/workflows eine Datei mit dem Namen release-please.yml mit folgendem Inhalt hinzu:
name: release-please
on:
push:
branches:
- main
workflow_dispatch:
permissions:
contents: write
pull-requests: write
jobs:
release-please:
runs-on: ubuntu-latest
steps:
- uses: google-github-actions/release-please-action@v3
with:
release-type: simple
Konventionelle Commits
Diese GitHub-Aktion prüft, ob eine Pull-Anfrage mit einem Titel geöffnet wird, der dem Standard für konventionelle Commits entspricht.
Fügen Sie dem Verzeichnis .github/workflows eine Datei mit dem Namen lint_pr_title.yml mit folgendem Inhalt hinzu:
name: "Lint Pull Request Title"
on:
pull_request_target:
types:
- opened
- edited
- synchronize
jobs:
main:
name: Validate PR title
runs-on: ubuntu-latest
steps:
- uses: amannn/action-semantic-pull-request@v5
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
permissions:
pull-requests:
read statuses: write
Änderungen per Push-Befehl an GitHub übertragen
Verwenden Sie schließlich die folgenden Befehle, um diese Änderungen an der GitHub-Aktion zu übernehmen und per Push an GitHub zu übertragen:
git add .github/workflows/
git commit -m "chore: Added github actions"
git push
main-Zweig schützen
Aktivieren Sie in der GitHub-Benutzeroberfläche den Schutz für den main-Branch, damit normale Entwickler keine Änderungen direkt in diesen Branch übertragen können. Stattdessen nehmen sie Änderungen in einem anderen Zweig vor und öffnen dann eine Pull-Anfrage. Die Pull-Anfrage kann von einem anderen Entwickler überprüft werden, bevor sie genehmigt und mit main zusammengeführt wird.
Um den Schutz von Branches zu konfigurieren, rufen Sie die GitHub-Benutzeroberfläche für das Repository auf, wählen Sie Einstellungen und dann Branches aus und klicken Sie auf die Schaltfläche Regel für den Schutz von Branches hinzufügen:
Geben Sie main als Zweig-Namensmuster ein und aktivieren Sie die folgenden Optionen:
- Pull-Anfrage vor dem Zusammenführen erforderlich
- Genehmigungen erforderlich
- Veraltete Pull-Anfrage-Genehmigungen verwerfen, wenn neue Commits gepusht werden
Klicken Sie schließlich unten auf der Seite auf den Button Erstellen.
Wenn eine Pull-Anfrage erstellt wird, werden die GitHub-Aktionen ausgeführt, die zuvor in dieser Anleitung konfiguriert wurden. Nachdem sie zum ersten Mal ausgeführt wurden, können sie auch in dieser Benutzeroberfläche ausgewählt werden, sodass sie erfolgreich abgeschlossen werden müssen, bevor die Pull-Anfrage in main zusammengeführt werden kann.
Pull-Anfragen konfigurieren
In Looker können Sie festlegen, dass Pull-Anfragen verwendet werden müssen, und Looker kann PRs im Namen des Entwicklers öffnen. Dies sollte nur für die Entwicklungsinstanz konfiguriert werden. Die QA- und Produktionsinstanz verwenden den erweiterten Bereitstellungsmodus, um ihre Updates zu erhalten.
Aktivieren Sie diese Option, indem Sie für jedes Projekt die Seite Projektkonfiguration aufrufen und unter der Überschrift GitHub-Integration die Option Pull-Anfragen erforderlich auswählen.
Klicken Sie auf den Button, um ein Webhook-Secret festzulegen, kopieren Sie den generierten zufälligen String und klicken Sie auf den Button Projektkonfiguration speichern.
Wählen Sie in der GitHub-Benutzeroberfläche für Ihr Repository Settings (Einstellungen) und dann Webhooks aus. Klicken Sie rechts oben auf den Button Webhook hinzufügen:
- Geben Sie im Feld Nutzlast-URL
https://LOOKER_HOST_NAME/webhooks/projects/PROJECT_NAME/deployein. - Fügen Sie im Feld Secret (Secret) das Secret ein, das Sie aus Looker gespeichert haben.
- Wählen Sie bei der Frage Welche Ereignisse sollen diesen Webhook auslösen? die Option Ich möchte einzelne Ereignisse auswählen aus.
Prüfen Sie, ob Pull Requests (Pull-Anfragen) und Pushes (Pushes) ausgewählt sind:
Klicken Sie abschließend unten auf der Seite auf den Button Webhook hinzufügen.
Einrichtungsschritte für jeden Looker-Entwickler
Alle folgenden Installationsschritte sollten in Ihrer Linux-Umgebung ausgeführt werden.
Ruby installieren
Die Programmiersprache Ruby muss installiert sein, damit Gazer ausgeführt werden kann. Jede Version von Ruby nach 2.7.7 funktioniert mit Gazer, aber Ruby 3.x.x wird bevorzugt. Führen Sie die folgenden Befehle aus, um Ruby unter Ubuntu Linux zu installieren:
sudo apt update
sudo apt install ruby
Prüfen Sie, ob Ruby richtig installiert ist. Führen Sie dazu ruby -v aus. Sie sollten eine Antwort ähnlich der folgenden erhalten:
ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux]
Diese Befehle funktionieren auch unter Debian Linux, Linux Mint und mehreren anderen Linux-Distributionen, die den Aptitude-Paketmanager verwenden. Möglicherweise müssen Sie nach Befehlen suchen, die auf anderen Linux-Versionen funktionieren, oder nach Befehlen, die unter macOS installiert werden können. Weitere Informationen finden Sie unter Ruby installieren.
Gazer installieren
Gazer ist ein Open-Source-Projekt, das von Google-Mitarbeitern entwickelt wurde, um Gruppenbereiche, Looks und Dashboards über ein Befehlszeilentool zu verwalten.
Wenn Ruby installiert ist, kann das Gem-Tool von Ruby verwendet werden, um Gazer zu installieren:
gem install gazer
Prüfen Sie mit dem Befehl gzr version, ob Gazer installiert ist. Sie sollten eine Antwort ähnlich der folgenden erhalten:
v0.3.12
Looker Continuous Integration einrichten
Verwenden Sie Looker Continuous Integration, um LookML zu testen und zu validieren. Die kontinuierliche Integration ist in Looker integriert und erfordert keine lokale CLI-Installation.
So verwenden Sie Continuous Integration:
- Prüfen Sie, ob Ihre Instanz die Anforderungen für die kontinuierliche Integration erfüllt.
- Ein Looker-Administrator muss Continuous Integration aktivieren und die CI-GitHub-App installieren.
- Erstellen Sie eine Continuous Integration-Suite, um die Validatoren und Trigger für Ihr Projekt zu konfigurieren.
Weitere Informationen finden Sie in der Dokumentation zur kontinuierlichen Integration von Looker.
Git installieren
Die Git-Versionsverwaltungssoftware kann mit diesem Befehl auf Ubuntu Linux installiert werden:
sudo apt update
sudo apt install git
Prüfen Sie mit dem Befehl git --version, ob die Installation erfolgreich war. Sie sollten eine Antwort ähnlich der folgenden erhalten:
git version 2.42.0.609.gbb76f46606
Diese Befehle funktionieren auch unter Debian Linux, Linux Mint und mehreren anderen Linux-Distributionen, die den Aptitude-Paketmanager verwenden. Möglicherweise müssen Sie nach Befehlen suchen, die auf anderen Linux-Versionen funktionieren. Anleitungen für Fedora und macOS finden Sie beispielsweise unter Getting Started – Installing Git.
Git konfigurieren
Git in Ihrer Linux-Umgebung muss so konfiguriert sein, dass es mit dem Git-Repository interagieren kann, in dem Ihre LookML gespeichert ist. Diese Anleitung wurde für LookML-Git-Repositories geschrieben, die in GitHub gespeichert sind.
Name und E-Mail-Adresse
GitHub (und die meisten anderen Git-Implementierungen) benötigen Ihren Namen und Ihre E-Mail-Adresse, um Aktivitäten aufzeichnen zu können. Konfigurieren Sie Ihren Namen und Ihre E‑Mail-Adresse in Git, indem Sie die folgenden Befehle ausführen:
git config --global user.name "FIRST_NAME LAST_NAME"
git config --global user.email "EMAIL_ADDRESS"
Git-Anmeldedaten
Bei der ersten CI/CD-Einrichtung wurden Git-Anmeldedaten erstellt. Der generierte private SSH-Schlüssel muss in einer $HOME/.ssh/config-Datei konfiguriert werden. Verwenden Sie die folgenden Befehle, um die Datei zu erstellen:
touch $HOME/.ssh/config
chmod 600 $HOME/.ssh/config
Fügen Sie den folgenden Text in die Datei $HOME/.ssh/config ein:
Host github.com
User git
IdentityFile ~/.ssh/KEY_NAME
ControlMaster auto
ControlPath ~/.ssh/ctrl-%r@%h:%p
ControlPersist yes
Verwenden Sie anstelle von KEY_NAME den Namen der privaten Schlüsseldatei, die Sie gemäß der Anleitung Einen neuen SSH-Schlüssel zu Ihrem GitHub-Konto hinzufügen generiert haben. Die Datei mit dem privaten Schlüssel hat denselben Namen wie die Datei mit dem öffentlichen Schlüssel, aber ohne die Erweiterung .pub. Wenn Sie beispielsweise den öffentlichen Schlüssel in der Datei id_ed25519.pub verwendet haben, heißt der private Schlüssel id_ed25519.
Lokales Git-Repository einrichten
Nachdem Sie Ihr LookML-Repository konfiguriert haben, müssen Sie eine Kopie davon in Ihrer Linux-Umgebung erstellen. Führen Sie dazu diesen Befehl aus:
git clone GIT_URL
Der Befehl könnte beispielsweise so aussehen:
git clone git@github.com:my_org_name/sales_project.git
Dadurch wird das LookML-Repository in ein Unterverzeichnis kopiert, z. B. sales_project. Verwenden Sie den Befehl cd SUB_DIRECTORY, um das Repository aufzurufen. In diesem Beispiel wäre der Befehl cd sales_project.
Sobald Sie sich im Verzeichnis Ihres Repositorys befinden, können Sie die folgenden Befehle verwenden:
| Befehl | Zweck |
|---|---|
git checkout BRANCH_NAME |
Wird zum Wechseln von Zweigen verwendet. In den meisten Fällen heißt der primäre Zweig main. In älteren Systemen kann er jedoch auch master heißen. |
git fetch |
Wird verwendet, um die neuesten Änderungen vom Server abzurufen. |
git pull |
Wird verwendet, um Änderungen auf die ausgecheckten lokalen Dateien anzuwenden. git pull führt implizit ein git fetch aus. |
git tag |
Wird verwendet, um ein aussagekräftiges Tag für eine bestimmte Überarbeitung zu erstellen. |
git push |
Wird verwendet, um lokale Änderungen auf den Server zu übertragen. |
Gazer konfigurieren
Wenn Sie Gazer verwenden möchten, benötigen Sie API-Anmeldedaten für jede der Entwicklungs-, QA- und Produktionsinstanzen. Eine Anleitung zum Erstellen von API-Anmeldedaten finden Sie auf der Seite Administratoreinstellungen – Nutzer. Die API-Anmeldedaten wurden möglicherweise bereits von der Person erstellt, die den CI/CD-Workflow ursprünglich eingerichtet hat. In diesem Fall können Sie die vorhandenen Anmeldedaten verwenden. Es müssen nicht für jede Person neue Anmeldedaten generiert werden.
Speichern Sie Ihre API-Anmeldedaten in einer .netrc-Datei mit minimalen Berechtigungen in Ihrem Basisverzeichnis. Mit den folgenden Befehlen können Sie eine leere Datei mit den richtigen Berechtigungen erstellen:
touch $HOME/.netrc
chmod 600 $HOME/.netrc
Fügen Sie der Datei Einträge wie die folgenden hinzu, verwenden Sie aber Ihre eigenen Looker-Server-Hostnamen für machine, die API client_id für die Anmeldung und die API client_secret für das Passwort. Beispiel:
machine dev.example.looker.com
login 80ka7nl6lj87ftmn
password u7kw3mj5h2trfz0
machine qa.example.looker.com
login fi3qtv5at5crvd1q
password bdxtaeghnzyz0wm
machine example.looker.com
login k7lr6yv57wvzy9p2
password wcvr5qjd2isbs2s
Testen Sie, ob dies funktioniert, indem Sie einen Gazer-Befehl für jeden Server ausführen, z. B. den folgenden:
gzr user me --host dev.example.looker.com
Das Ergebnis sollte in etwa so aussehen:
+----+---------------+---------+----------+------------------+--------------+
| id|email |last_name|first_name|personal_folder_id|home_folder_id|
+----+---------------+---------+----------+------------------+--------------+
|2345|jsm@example.com|Smith |John | 2161| 708|
+----+---------------+---------+----------+------------------+--------------+
Wenn der vorherige Befehl nicht funktioniert, müssen Sie möglicherweise --port 443 am Ende des gzr-Befehls hinzufügen:
gzr user me --host dev.example.looker.com --port 443
Continuous Integration-Suites konfigurieren
Erstellen Sie Continuous Integration-Suites in Looker, um Ihre Validierungsregeln und Testkonfigurationen anzugeben.
In einer CI-Suite können Sie Folgendes konfigurieren:
- Triggeroptionen, um die Validierung automatisch bei Pull-Anfragen, nach Zeitplan oder manuell über die Looker-IDE auszuführen.
- SQL-Validator, um Dimensionen anhand der Datenbank zu testen.
- Assert Validator zum Ausführen von LookML-Datentests.
- Inhaltsvalidierung zum Testen von Looks und Dashboards
- LookML-Validator zum Prüfen der LookML-Syntax
- Stil-Validator, um LookML-Codierungsstandards, Namenskonventionen und strukturelle Best Practices in Ihrem Projekt durchzusetzen.
Eine Anleitung zum Konfigurieren von Suiten finden Sie unter Continuous Integration-Suite erstellen.