Versionsverwaltung und Bereitstellung verwenden

Auf dieser Seite wird davon ausgegangen, dass die Versionsverwaltung für Ihr Projekt bereits eingerichtet wurde. Wenn anstelle der auf dieser Seite beschriebenen Optionen die Schaltfläche Git konfigurieren angezeigt wird, müssen Sie zuerst Git für Ihr Projekt einrichten.

Looker verwendet Git, um Änderungen aufzuzeichnen und Dateiversionen zu verwalten. Jedes LookML-Projekt entspricht einem Git-Repository und jeder Entwicklerzweig korreliert mit einem Git-Zweig.

Looker kann so konfiguriert werden, dass es mit vielen Git-Anbietern wie GitHub, GitLab und Bitbucket funktioniert. Informationen zum Einrichten von Git für Ihr Looker-Projekt finden Sie auf der Dokumentationsseite Git-Verbindung einrichten und testen.

Mit Git-Zweigen arbeiten

Einer der Hauptvorteile von Git besteht darin, dass ein Looker-Entwickler in einem Branch arbeiten kann, einer isolierten Version eines Datei-Repositorys. Sie können entwickeln und testen, ohne andere Nutzer zu beeinträchtigen. Als Entwickler in Looker verwenden Sie immer einen Git-Zweig, wenn Sie sich im Entwicklungsmodus befinden.

Ein weiteres wichtiges Feature von Git ist die einfache Zusammenarbeit mit anderen Entwicklern. Sie können einen Zweig erstellen und bei Bedarf Änderungen vornehmen. Anschließend können andere Entwickler zu diesem Zweig wechseln, um ihn zu prüfen oder zu ändern. Wenn ein anderer Entwickler Änderungen am Zweig festgeschrieben hat, zeigt Looker die Schaltfläche Remote-Änderungen abrufen an. Sie sollten diese übernommenen Änderungen am Zweig abrufen, bevor Sie weitere Änderungen vornehmen.

Sie können auch einen anderen Zweig als den Master-Branch, Ihren aktuellen Zweig oder den persönlichen Zweig eines Entwicklers löschen.

Persönliche Zweige

Wenn Sie den Entwicklungsmodus zum ersten Mal aufrufen, erstellt Looker automatisch Ihren persönlichen Git-Zweig. Dein persönlicher Zweig beginnt mit dev- und enthält deinen Namen.

Ihr persönlicher Zweig ist nur für Sie sichtbar und er kann nicht gelöscht werden. Ihr persönlicher Zweig ist für alle anderen Entwickler schreibgeschützt. Wenn Sie mit anderen Entwicklern an einem Projekt arbeiten, können Sie einen neuen Zweig erstellen, damit andere zu diesem Zweig wechseln und ebenfalls Änderungen beitragen können.

Neuen Git-Zweig erstellen

Wenn Sie an einer einfachen Lösung arbeiten und nicht mit anderen Entwicklern zusammenarbeiten, ist Ihr persönlicher Zweig in der Regel ein guter Arbeitsplatz. Sie können über Ihren persönlichen Zweig schnelle Aktualisierungen vornehmen und dann die Änderungen mit einem Commit in die Produktion übertragen.

Möglicherweise möchten Sie jedoch zusätzlich zu Ihrem persönlichen Zweig auch neue Git-Zweige erstellen. In folgenden Situationen ist ein neuer Git-Zweig sinnvoll:

  • Sie arbeiten mit anderen Entwicklern zusammen. Da Ihr persönlicher Zweig für andere Entwickler schreibgeschützt ist, sollten Sie einen neuen Git-Zweig erstellen, damit andere Entwickler in den Zweig schreiben können, wenn Sie mit anderen zusammenarbeiten möchten. Wenn Sie mit anderen zusammenarbeiten, achten Sie darauf, bei jeder Wiederaufnahme der Arbeit die Änderungen abzurufen. So haben Sie die neuesten Updates von allen Entwicklern, bevor Sie weiterarbeiten.
  • Sie arbeiten an mehreren Gruppen von Funktionen gleichzeitig. Manchmal befinden Sie sich mitten in einem großen Projekt, möchten aber ein kleineres Problem lösen oder eine schnelle Lösung vornehmen. In diesem Fall können Sie Ihre Änderungen per Commit auf den Zweig übertragen, auf dem Sie sich befinden, und dann einen anderen Zweig erstellen oder zu einem anderen Zweig wechseln, um an einem separaten Satz von Funktionen zu arbeiten. Sie können die Fehlerbehebung im neuen Zweig vornehmen und dann die Änderungen dieses Zweigs für die Produktion bereitstellen, bevor Sie die Arbeit im ursprünglichen Zweig fortsetzen.

Bevor Sie einen neuen Zweig erstellen:

  • Wenn für den aktuellen Zweig ein Zusammenführungskonflikt vorliegt, müssen Sie den Konflikt beheben, bevor Sie einen neuen Zweig erstellen können.
  • Wenn für den aktuellen Zweig Änderungen ohne Commit vorhanden sind, müssen Sie für den aktuellen Zweig ein Commit durchführen, bevor Sie einen neuen Zweig erstellen.
  • Wenn Sie einen Zweig aus einem vorhandenen Entwicklungszweig (und nicht aus dem Produktionszweig) erstellen möchten, rufen Sie zuerst die neueste Version des Entwicklungszweigs ab. Wechseln Sie dazu zu diesem Entwicklungszweig und rufen Sie Änderungen per Pull ab, um die lokale Version dieses Zweigs zu synchronisieren.

So erstellen Sie einen neuen Git-Zweig:

  1. Prüfen Sie, ob der Entwicklungsmodus aktiviert ist.

  2. Rufen Sie Ihre Projektdateien im Menü Entwickeln auf.

  3. Wählen Sie im Symbolmenü links das Git-Symbol aus, um den Bereich Git Actions (Git-Aktionen) zu öffnen.

  4. Wählen Sie das Drop-down-Menü Zweige anzeigen aus.

  5. Wählen Sie New Branch (Neuer Zweig) aus.

  6. Geben Sie im Fenster Neuer Zweig einen Namen für den Zweig ein. Beachten Sie, dass es Einschränkungen für Git-Branch-Namen gibt. Informationen zu den Anforderungen für die Benennung finden Sie auf dieser Seite unter Regeln zum Benennen eines Git-Zweigs.

  7. Klicken Sie auf das Drop-down-Menü Create aus (Erstellen aus) und wählen Sie einen bestehenden Branch als Ausgangspunkt für den neuen Branch aus.

  8. Wählen Sie Erstellen aus, um Ihren Branch zu erstellen.

Alternativ können Sie Git-Zweige auch über den Tab Branch Management der Seite Projekteinstellungen erstellen.

Regeln zum Benennen eines Git-Zweigs

Looker verwendet die von Git angegebenen Anforderungen an die Zweigbenennungskonvention.

Git-Branch-Namen dürfen nicht:

  • Leerzeichen enthalten
  • Enthält einen doppelten Punkt: ..
  • einen umgekehrten Schrägstrich enthalten: \
  • Enthalten die Sequenz: @{
  • Enthält ein Fragezeichen: ?
  • Enthält eine öffnende eckige Klammer: [
  • Ein ASCII-Steuerzeichen enthalten: ~, \^ oder :
  • Mit einem Punkt beginnen: .
  • Beginnen Sie mit dem Präfix: dev- (reserviert für persönliche Zweige von Looker-Entwicklern)
  • Mit einem Schrägstrich enden: /
  • Mit dieser Erweiterung enden: .lock

Außerdem darf der Zweigname nur dann ein Sternchen (*) enthalten, wenn das Sternchen eine ganze Pfadkomponente darstellt (z. B. foo/* oder bar/*/baz). In diesem Fall wird es als Platzhalter und nicht als Teil des tatsächlichen Zweignamens interpretiert.

Zu einem anderen Git-Zweig wechseln

Wenn in Ihrem aktuellen Zweig ein Zusammenführungskonflikt vorliegt, müssen Sie den Konflikt beheben, bevor Sie zu einem anderen Zweig wechseln können.

Falls Änderungen in Ihrem aktuellen Zweig ohne Commit durchgeführt wurden, können Sie erst dann zu einem vorhandenen Zweig wechseln, wenn Sie für den aktuellen Zweig ein Commit durchführen.

So wechseln Sie zu einem anderen Git-Zweig:

  1. Gehen Sie im Projekt zum Bereich Git Actions (Git-Aktionen), indem Sie links im Symbolmenü das Symbol Git auswählen.
  2. Wählen Sie im Bereich Git Actions (Git-Aktionen) das Drop-down-Menü für den Git-Zweig rechts neben dem Namen Ihres aktuellen Git-Zweigs aus.
  3. Wählen Sie den Zweig aus, zu dem Sie wechseln möchten, indem Sie ihn im Menü auswählen oder indem Sie den Zweignamen in das Suchfeld eingeben. Bei der Suche nach Zweignamen wird die Groß-/Kleinschreibung nicht berücksichtigt. Wenn Sie beispielsweise nach „DEV“ suchen, werden alle Zweige mit den Namen „dev“, „DEV“, „Dev“ usw. angezeigt.

Git-Zweige verwalten

Auf dem Tab Branch Management der Seite Projekteinstellungen wird eine Tabelle mit allen Git-Zweigen für das Looker-Projekt angezeigt. Um den Tab Branch Management zu öffnen, rufen Sie zuerst die Seite Project Settings (Projekteinstellungen) auf. Wählen Sie dazu im Symbolmenü links das Symbol Settings (Einstellungen) aus. Wählen Sie als Nächstes den Tab Branch Management aus.

Auf dem Tab Branch Management haben Sie folgende Möglichkeiten:

  1. Erstellen Sie einen neuen Zweig, indem Sie auf die Schaltfläche New Branch klicken. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Neuen Git-Zweig erstellen.
  2. Suchen Sie in der Suchleiste nach Zweignamen.
  3. Um die Tabelle zu aktualisieren, klicken Sie auf die Schaltfläche Aktualisieren.
  4. Sortieren Sie die Tabelle, indem Sie einen Spaltennamen auswählen.

Die Tabelle enthält die folgenden Informationen:

  • Name: Name des Git-Zweigs. Die persönlichen Zweige von Looker-Entwicklern beginnen mit dev- und enthalten den Vor- und Nachnamen des Entwicklers.
  • Status: Die Differenz zwischen der lokalen Version des Zweigs und der Remote-Version des Zweigs. Der Status 3 commits behind bedeutet beispielsweise, dass Ihre lokale Version des Zweigs drei Commits hinter der Remote-Version des Zweigs liegt. Da Looker immer die Remote-Version des Masters verwendet, wird auf dem Tab Branch Management nicht der Status der lokalen Version des Master-Zweigs angezeigt. Der Master-Zweig kann immer als aktuell angesehen werden.
  • Zuletzt aktualisiert: Zeitraum, seit dem ein Looker-Entwickler ein Commit für den Zweig durchgeführt hat.
  • Aktionen: Eine Schaltfläche zum Löschen des Zweigs oder der Grund, warum der Zweig nicht gelöscht werden kann.

Git-Zweige löschen

Auf dem Tab Branch Management können Sie Zweige löschen, für die in der Tabelle die Schaltfläche Löschen angezeigt wird. Sie können die folgenden Zweige nicht löschen:

In der Tabelle haben diese Zweige keine Schaltfläche Löschen. Stattdessen wird in der Spalte Action der Tabelle der Grund angezeigt, warum der Zweig nicht gelöscht werden kann.

Sie können einen Zweig nicht wiederherstellen, nachdem er gelöscht wurde. Wenn Sie einen Zweig löschen, entfernt Looker sowohl die lokale Version als auch die Remote-Version des Zweigs.

Wenn der Zweig jedoch von einem anderen Looker-Entwickler erstellt wurde oder wenn andere Entwickler ihn ausgecheckt haben, haben diese Entwickler immer noch ihre lokale Version des Zweigs. Wenn ein Looker-Entwickler Commits für seine lokale Version des Zweigs durchführt und ihn in die Produktion überträgt, wird wieder eine Remote-Version des Zweigs angezeigt. Das kann praktisch sein, wenn Sie den Zweig wiederherstellen möchten. Wenn Sie einen Zweig löschen, sollten alle anderen Looker-Entwickler denselben Zweig löschen, um sicherzustellen, dass er nicht versehentlich von jemandem, der ihn per Push-Funktion per Remote-Zugriff übertragen, wieder angezeigt wird.

Zum Löschen eines oder mehrerer Git-Zweige aus Ihrem Projekt rufen Sie zuerst die Seite Projekteinstellungen auf. Wählen Sie dazu im Symbolmenü links das Symbol Einstellungen aus. Wählen Sie dann den Tab Branch Management aus. Im Tab Branch Management können Sie Zweige auf zwei Arten löschen:

  1. Löschen Sie mehrere Zweige. Klicken Sie dazu zuerst auf die Kästchen für Zweige und dann auf Ausgewählte Zweige löschen.
  2. Um einen einzelnen Zweig zu löschen, wählen Sie neben dem Namen des Zweigs Löschen aus.

Git-Befehle in Looker ausführen

Looker verfügt über eine integrierte Schnittstelle, die sich in Ihren Git-Dienst einbinden lässt. In Looker wird die Git-Schaltfläche oben rechts in der LookML-IDE angezeigt.

Die Git-Schaltfläche zeigt verschiedene Optionen an, je nachdem, wo Sie gerade Änderungen vornehmen und die Bereitstellung für die Produktion ausführen. Im Allgemeinen ist die auf der Schaltfläche angezeigte Option die beste Orientierungshilfe für Ihre nächste Aktion.

Wenn Ihr Entwickler-Branch mit dem Produktions-Branch synchronisiert ist, wird auf der Git-Schaltfläche die Meldung Up to Date angezeigt und kann nicht ausgewählt werden.

Sobald Ihr Projekt für Git konfiguriert ist, können Sie die Schaltfläche Git Actions (Git-Aktionen) anklicken, um den Bereich Git Actions (Git-Aktionen) zu öffnen.

Welche Befehle im Bereich Git Actions verfügbar sind, hängt davon ab, in welcher Phase Sie gerade Änderungen vornehmen und in der Produktionsumgebung bereitstellen.

Änderungen werden in die Produktion übernommen

Bei der standardmäßigen Looker-Git-Integration führt Looker Entwickler durch den folgenden Git-Workflow:

Das bedeutet, dass bei der standardmäßigen Git-Integration alle Entwickler ihre Änderungen in einem Zweig namens master zusammenführen. Der letzte Commit im Zweig master wird für die Produktionsumgebung von Looker verwendet.

Bei erweiterten Git-Implementierungen können Sie diesen Workflow anpassen:

  • Sie können Ihre Entwickler Pull-Anfragen für Ihren Git-Produktionszweig senden lassen, anstatt Entwicklern zu erlauben, ihre Änderungen über die Looker-IDE zusammenzuführen. Weitere Informationen finden Sie auf der Dokumentationsseite Einstellungen für die Projektversionsverwaltung konfigurieren.
  • Im Feld Name des Git-Produktionszweigs können Sie angeben, welchen Zweig aus Ihrem Git-Repository Looker als Zielzweig verwenden soll, in dem die Zweige Ihrer Looker-Entwickler zusammengeführt werden. Weitere Informationen finden Sie auf der Dokumentationsseite Einstellungen für die Projektversionsverwaltung konfigurieren.
  • Sie können den erweiterten Bereitstellungsmodus verwenden, um einen anderen Commit-SHA oder einen anderen Tag-Namen für die Bereitstellung in der Looker-Produktionsumgebung anzugeben, anstatt den neuesten Commit im Produktionszweig zu verwenden. Wenn Sie einen Commit von einem anderen Zweig bereitstellen möchten, können Sie den Webhook- oder API-Endpunkt im erweiterten Bereitstellungsmodus verwenden. Weitere Informationen finden Sie auf der Dokumentationsseite Erweiterter Bereitstellungsmodus.

Wenn anstelle der in diesem Abschnitt beschriebenen Optionen die Schaltfläche Git konfigurieren angezeigt wird, müssen Sie zuerst Git für Ihr Projekt einrichten.

Änderungen ohne durchgeführten Commit ansehen

Die LookML-IDE hat mehrere Indikatoren, die angezeigt werden, wenn Sie sich im Entwicklungsmodus befinden und Änderungen ohne Commit vorgenommen haben, wie im Abschnitt Ergänzungen, Änderungen und Löschungen markieren auf der Dokumentationsseite LookML bearbeiten und validieren beschrieben.

Sie können eine Differenzzusammenfassung für alle Dateien abrufen, indem Sie im Bereich Git Actions (Git-Aktionen) die Option View Uncommitted Changes (Änderungen ohne durchgeführten Commit ansehen) auswählen.

Im Fenster Änderungen am Projekt ohne Commit zeigt Looker eine Zusammenfassung aller gespeicherten Änderungen in allen Projektdateien ohne durchgeführten Commit an. Für jede Änderung zeigt Looker Folgendes an:

  • Der Name der ersetzten Datei und der Name der hinzugefügten Datei.
    • Der Name der ersetzten Datei (gekennzeichnet durch ---) und der Name der hinzugefügten Datei (gekennzeichnet durch +++). In vielen Fällen werden hier verschiedene Versionen derselben Datei angezeigt, die mit --- a/ und +++ b/ gekennzeichnet sind.
    • Es wird angezeigt, dass gelöschte Dateien eine Nulldatei ersetzen (+++ /dev/null).
    • Es wird angezeigt, dass hinzugefügte Dateien eine Nulldatei ersetzen (--- /dev/null).
  • Die Nummer der Zeile, in der die Änderung beginnt.

    Das -101,4 +101,4 gibt beispielsweise an, dass in der 101. Zeile der Datei 4 Zeilen entfernt und 4 Zeilen hinzugefügt wurden. Bei einer gelöschten Datei mit 20 Zeilen wird -1,20 +0,0 angezeigt. Das bedeutet, dass in der ersten Zeile der Datei 20 Zeilen entfernt und durch null ersetzt wurden.
  • Der Text, der aktualisiert wurde:
    • Gelöschte Linien werden rot dargestellt.
    • Hinzugefügte Linien werden in Grün angezeigt.

Um eine Differenzzusammenfassung für eine einzelne Datei aufzurufen, wählen Sie im Menü der Datei die Option Änderungen anzeigen aus.

Änderungen übernehmen

Nachdem Sie Änderungen an Ihrem LookML-Projekt vorgenommen und gespeichert haben, fordert die IDE Sie möglicherweise auf, Ihren LookML-Code zu validieren. Die Git-Schaltfläche zeigt in diesem Szenario den Text LookML validieren an.

Ob dies erforderlich ist, hängt von der Einstellung für die Codequalität in Ihrem Projekt ab. Weitere Informationen zur Inhaltsvalidierung finden Sie auf der Dokumentationsseite LookML validieren.

Wenn ein anderer Entwickler seit der letzten Aktualisierung des lokalen Zweigs Änderungen am Produktionszweig vorgenommen hat, müssen Sie diese Aktualisierungen von Looker aus dem Produktionszweig abrufen. Die Git-Schaltfläche zeigt in diesem Szenario den Text Aus Produktion abrufen an.

Wenn Ihr Projekt für den erweiterten Bereitstellungsmodus aktiviert ist, zeigt die Git-Schaltfläche stattdessen den Text Pull from Primary Branch an.

Sobald Sie Ihre Änderungen gespeichert (und alle LookML-Warnungen oder -Fehler behoben haben, falls erforderlich) und Daten aus der Produktion abgerufen haben (falls erforderlich), zeigt die Git-Schaltfläche den Text Commit Änderungen & Push an.

Bei Bedarf können Sie die Änderungen ohne durchgeführten Commit prüfen, bevor Sie einen Commit durchführen.

Wenn Sie bereit sind, die Änderungen per Commit zu übernehmen, verwenden Sie die Git-Schaltfläche, um diese Änderungen an Ihren aktuellen Zweig zu übertragen. In Looker wird das Dialogfeld Commit mit den Dateien angezeigt, die hinzugefügt, geändert oder gelöscht wurden.

Geben Sie eine Nachricht ein, in der Ihre Änderungen kurz beschrieben werden, und deaktivieren Sie die Kontrollkästchen neben allen Dateien, die nicht in die Synchronisierung einbezogen werden sollen. Wählen Sie dann Commit aus, um die Änderungen zu übernehmen.

Auf nicht erstellte PATs prüfen

Wenn Sie Änderungen an PDTs in Ihrem Projekt vorgenommen haben, ist es optimal, dass alle Ihre PDTs bei der Bereitstellung für die Produktion erstellt werden, damit die Tabellen sofort als Produktionsversionen verwendet werden können. Um den Status von PATs im Projekt zu prüfen, klicken Sie auf das Symbol Project Health (Projektzustand), um den Bereich Project Health (Projektzustand) zu öffnen, und wählen Sie dann die Schaltfläche Validate PDT Status (PDT-Status validieren) aus.

Weitere Informationen zum Suchen nach nicht erstellten PATs in Ihrem LookML-Projekt und zum Arbeiten mit abgeleiteten Tabellen im Entwicklungsmodus finden Sie auf der Dokumentationsseite Abgeleitete Tabellen in Looker.

Datentests ausführen

Ihr Projekt kann einen oder mehrere test-Parameter enthalten, die Datentests definieren, um die Logik Ihres LookML-Modells zu prüfen. Auf der Dokumentationsseite zum Parameter test finden Sie Informationen zum Einrichten von Datentests in Ihrem Projekt.

Wenn Ihr Projekt Datentests enthält und Sie sich im Entwicklungsmodus befinden, können Sie die Datentests Ihres Projekts auf verschiedene Arten initiieren:

  1. Wenn Ihre Projekteinstellungen so konfiguriert sind, dass Datentests vor der Bereitstellung Ihrer Dateien für die Produktion bestanden werden müssen, zeigt die IDE die Schaltfläche Tests ausführen an, nachdem Sie Änderungen am Projekt mit einem Commit durchgeführt, um alle Tests für Ihr Projekt auszuführen, unabhängig davon, welche Datei den Test definiert. Sie müssen die Datentests bestehen, bevor Sie Ihre Änderungen für die Produktion bereitstellen können.
  2. Wählen Sie im Bereich Projektzustand die Schaltfläche Datentests ausführen aus. Looker führt alle Datentests in Ihrem Projekt aus, unabhängig davon, welche Datei den Test definiert.
  3. Wählen Sie im Menü der Datei die Option LookML-Tests ausführen aus. Looker führt nur die Tests aus, die in der aktuellen Datei definiert sind.

Nachdem Sie die Datentests ausgeführt haben, werden im Bereich Project Health der Fortschritt und die Ergebnisse angezeigt.

  • Ein Datentest ist bestanden, wenn die Assertion des Tests für jede Zeile der Testabfrage wahr ist. Weitere Informationen zum Einrichten von TestAssertions und Abfragen finden Sie auf der Dokumentationsseite zum Parameter test.
  • Wenn ein Datentest fehlschlägt, finden Sie im Bereich Project Health (Projektzustand) Informationen darüber, warum der Test fehlgeschlagen ist, ob der Test Fehler in der Logik Ihres Modells gefunden hat oder ob es der Test selbst war, der ungültig war.
  • In den Ergebnissen des Datentests können Sie den Namen eines Datentests auswählen, um direkt zu LookML für den Datentest zu wechseln. Alternativ können Sie auf die Schaltfläche Abfrage ansehen klicken, um ein Explore mit der im Datentest definierten Abfrage zu öffnen.

In der Produktion bereitstellen

Sobald Sie die Änderungen an Ihrem Zweig übernommen haben, werden Sie von der Looker-IDE aufgefordert, die Änderungen mit dem primären Zweig zusammenzuführen. Die Art der Eingabeaufforderung, die in der IDE angezeigt wird, hängt von der Konfiguration Ihres Projekts ab:

  • Wenn Ihr Projekt für den erweiterten Bereitstellungsmodus konfiguriert ist, werden Sie von der IDE aufgefordert, Ihre Änderungen im primären Zweig zusammenzuführen. Nachdem Sie den Commit zusammengeführt haben, kann ein Looker-Entwickler mit der Berechtigung deploy ihn für die Produktion bereitstellen. Verwenden Sie dazu den Deployment Manager der Looker IDE oder einen Webhook oder einen API-Endpunkt.
  • Wenn Ihr Projekt für die Git-Integration mit Pull-Anfragen konfiguriert ist, werden Sie aufgefordert, über die Benutzeroberfläche Ihres Git-Anbieters eine Pull-Anfrage zu öffnen.
  • Andernfalls werden Sie bei der standardmäßigen Looker-Git-Integration mit der deploy-Berechtigung von der Looker-IDE aufgefordert, Ihre Änderungen im Produktionszweig zusammenzuführen und sie in der Produktionsversion Ihrer Looker-Instanz bereitzustellen.

Erweiterter Bereitstellungsmodus

Bei der standardmäßigen Looker-Git-Integration übernehmen Looker-Entwickler ihre Änderungen in ihrem Entwicklungszweig und führen dann ihren Entwicklungszweig mit dem Produktionszweig zusammen. Wenn Sie die Bereitstellung dann in der Looker-Umgebung durchführen, verwendet Looker den neuesten Commit im Produktionszweig. Informationen zum Standard-Git-Workflow und zu anderen Optionen für erweiterte Git-Implementierungen finden Sie im Abschnitt Änderungen an der Produktion vornehmen auf dieser Seite.

Wenn Sie nicht immer den neuesten Commit im Produktionszweig für Ihre Looker-Umgebung verwenden möchten, kann ein Entwickler mit der Berechtigung deploy im erweiterten Bereitstellungsmodus den genauen Commit angeben, der für Ihre Looker-Umgebung verwendet werden soll. Dies ist in Entwickler-Workflows mit mehreren Umgebungen nützlich, bei denen jede Umgebung auf eine andere Version einer Codebasis verweist. Außerdem erhalten ein oder mehrere Entwickler oder Administratoren mehr Kontrolle über die Änderungen, die für die Produktion bereitgestellt werden.

Wenn der erweiterte Bereitstellungsmodus aktiviert ist, fordert die Looker-IDE Entwickler nicht auf, ihre Änderungen für die Produktion bereitzustellen. Stattdessen fordert die IDE die Entwickler auf, ihre Änderungen im Produktionszweig zusammenzuführen. Ab dann können Änderungen nur noch auf folgende Arten bereitgestellt werden:

  • Deployment Manager in der Looker-IDE verwenden
  • Webhook auslösen

  • API-Endpunkt verwenden

Weitere Informationen finden Sie auf der Dokumentationsseite Erweiterter Bereitstellungsmodus.

Auswirkungen Ihrer Änderungen prüfen

Nachdem Sie Ihre Änderungen für die Organisation verfügbar gemacht haben, können Sie mithilfe der Inhaltsvalidierung sicherstellen, dass Sie keine Dashboards oder gespeicherten Looks ungültig gemacht haben. Sie haben die Möglichkeit, diese zu beheben.

Umgang mit typischen Problemen

Bei der Arbeit an Ihrem Modell müssen Sie möglicherweise Folgendes tun:

  • Änderungen verwerfen

    Gelegentlich möchten Sie Ihre Änderungen an der Datenmodellierung verwerfen. Falls sie noch nicht gespeichert wurden, können Sie sie einfach aktualisieren oder die Seite verlassen und dann die Warnmeldung akzeptieren. Wenn Sie die Änderungen gespeichert haben, können Sie die Änderungen ohne Commit zurücksetzen, wie im Abschnitt Änderungen ohne Commit zurücksetzen beschrieben.

  • Zusammenführungskonflikte mit der Arbeit anderer Entwickler handhaben

    Wenn mehr als ein Entwickler an Ihrem Datenmodell arbeitet, kümmert sich Git in der Regel um die Situation. Gelegentlich benötigt Git jedoch einen Mitarbeiter, der Zusammenführungskonflikte löst.

Einige Änderungen, z. B. das Ändern des Feldnamens, können sich auf vorhandene Dashboards und Looks auswirken. Wie bereits erwähnt, können Sie mit der Inhaltsvalidierung Ihre Inhalte überprüfen und Probleme beheben, nachdem Sie die Änderungen für die Organisation freigegeben haben.

Änderungen ohne durchgeführten Commit zurücksetzen

Wenn Sie an Ihrem persönlichen Entwicklungszweig arbeiten, können Sie gespeicherte Änderungen ohne Commit zurücksetzen, wenn Sie sie nicht bereitstellen möchten. Sie können alle Änderungen ohne Commit für alle Dateien im Projekt oder nur für die Änderungen in einer einzelnen Datei rückgängig machen.

So machen Sie Änderungen ohne Commit für alle Dateien rückgängig:

  1. Wählen Sie im Bereich Git Actions (Git-Aktionen) die Option Reset to... (Wiederherstellen auf...) aus.
  2. Wählen Sie eine Option zum Wiederherstellen aus:
    • Wenn Sie nur Änderungen ohne Commit zurücksetzen möchten, wählen Sie Änderungen ohne Commit zurücksetzen aus. Sie können auch auf den Link Änderungen anzeigen klicken, um die Änderungen aufzurufen, die rückgängig gemacht würden.
    • Wenn Sie alle Änderungen rückgängig machen möchten, einschließlich Änderungen ohne Commit und Commit, wählen Sie Auf Produktion zurücksetzen aus.
  3. Wählen Sie Bestätigen aus, um das Zurücksetzen abzuschließen.

Um das Hinzufügen oder Löschen von Inhalten einer einzelnen Datei rückgängig zu machen, wählen Sie im Menü der Datei die Option Änderungen rückgängig machen:

Wenn Sie eine Datei umbenennen, löschen Sie damit die ursprüngliche Datei und erstellen eine neue Datei mit einem neuen Namen. Da dabei mehrere Dateien betroffen sind, können Sie das Umbenennen einer Datei nicht mit der Option Datei wiederherstellen rückgängig machen. Wenn Sie die Umbenennung einer Datei rückgängig machen möchten, verwenden Sie die Option Reset to... (Wiederherstellen in...) im Bereich Git Actions (Git-Aktionen).

Wenn Sie eine Datei gelöscht haben, wird sie außerdem nicht mehr im IDE-Dateibrowser angezeigt. Wenn Sie das Löschen einer Datei rückgängig machen möchten, verwenden Sie die Option Wiederherstellen in... im Bereich Git Actions (Git-Aktionen).

Zusammenführungskonflikte beheben

In der Regel kann Git Ihre neuen Änderungen automatisch mit der Produktionsversion Ihrer LookML-Dateien zusammenführen. Ein Zusammenführungskonflikt tritt auf, wenn Git in Konflikt stehende Änderungen findet und nicht ermitteln kann, welche Änderungen beibehalten werden sollten. Dies ist normalerweise der Fall, wenn ein anderer Entwickler Änderungen seit dem letzten Abruf vorgenommen hat und Sie Änderungen im selben Bereich vorgenommen haben. Wenn in Ihrem Code ein Zusammenführungskonflikt auftritt, zeigt Looker die Warnung Zusammenführungskonflikte an, nachdem Sie einen Commit für Änderungen durchgeführt und Daten aus der Produktion abgerufen haben.

Wenn in Looker die Warnung zum Zusammenführungskonflikt angezeigt wird, sollten Sie den Zusammenführungskonflikt beheben, bevor Sie weitere Änderungen vornehmen. Wenn Sie einen Zusammenführungskonflikt an die Produktion senden, treten Parsing-Fehler auf, die möglicherweise eine Untersuchung Ihrer Daten verhindern. Wenn Sie ein erfahrener Git-Nutzer sind und Änderungen vornehmen möchten, klicken Sie auf die Schaltfläche Don't Resolve (Nicht beheben).

In der LookML-Datei selbst sind die Zeilen mit Konflikten wie folgt markiert:

<<<<<<< HEAD
Your code
&#61;&#61;&#61;&#61;&#61;&#61;&#61;
Production code
>>>>>>> branch 'master'

Looker zeigt die folgenden Zusammenführungsmarkierungen an, um auf Zusammenführungskonflikte hinzuweisen:

  • <<<<<<< HEAD markiert den Anfang der in Konflikt stehenden Zeilen.
  • >>>>>>> branch 'master' markiert das Ende der in Konflikt stehenden Zeilen.
  • Mit ======= werden die einzelnen Versionen des Codes voneinander getrennt, damit Sie sie vergleichen können.

Im vorherigen Beispiel steht your code für die Änderungen, für die Sie einen Commit durchgeführt haben, und production code für den Code, in den Git Ihre Änderungen nicht automatisch zusammenführen konnte.

So lösen Sie einen Zusammenführungskonflikt:

  1. Suchen Sie die Dateien mit Zusammenführungskonflikten. Looker markiert diese Dateien rot. Alternativ können Sie auch in Ihrem Projekt nach Zusammenführungsmarkierungen wie <<<< oder HEAD suchen, um alle Konflikte in Ihrem Projekt zu finden. Sie können die betroffenen Dateien auch finden, indem Sie in der Zusammenführungswarnung, die im Bereich Git-Aktionen angezeigt wird, auf den Link Dateien klicken.
  2. Gehen Sie in der Datei zu den Zeilen mit Zusammenführungskonflikten und löschen Sie die Version des Textes, die Sie NICHT beibehalten möchten. Löschen Sie auch alle Markierungen für den Zusammenführungskonflikt.

  3. Speichern Sie die Datei und wiederholen Sie die vorherigen Schritte für alle anderen Dateien, die mit Zusammenführungskonflikten gekennzeichnet sind.

  4. Nachdem Sie alle Zusammenführungskonflikte gelöst und alle Zusammenführungsmarkierungen aus Ihrem Projekt gelöscht haben, führen Sie einen Commit für die Änderungen durch und stellen sie für die Produktion bereit.

Nachdem Sie den Zusammenführungskonflikt gelöst und Ihre Lösung in die Produktion übernommen haben, können andere Entwickler die Produktion übernehmen und wie gewohnt weiterarbeiten.

Git-automatische Speicherbereinigung

Die Git-automatische Speicherbereinigung bereinigt unnötige Dateien und komprimiert Dateiversionen, um Ihr Git-Repository zu optimieren. Die automatische Git-automatische Speicherbereinigung (git gc) wird automatisch ausgeführt, wenn Ihre Looker-Instanz aktualisiert oder neu gestartet wird. Damit git gc nicht zu oft ausgeführt wird, wartet Looker seit dem letzten git gc 30 Tage und führt git gc beim nächsten Neustart aus.

In seltenen Fällen können Sie versuchen, Änderungen per Push-Befehl an Remote-Standort zu übertragen oder Zweig an Remote-Verbindung zu übertragen, während git gc ausgeführt wird. Wenn Looker einen Fehler anzeigt, warten Sie ein bis zwei Minuten und versuchen Sie dann noch einmal, Ihre Änderungen zu übertragen.