Versionsverwaltung verwenden und bereitstellen

Auf dieser Seite wird davon ausgegangen, dass Ihr Projekt bereits für die Versionskontrolle 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.

In Looker werden Änderungen mit Git aufgezeichnet und Dateiversionen verwaltet. Jedem LookML-Projekt entspricht ein Git-Repository und jeder Entwickler-Branch einem Git-Branch.

Looker kann für die Verwendung mit vielen Git-Anbietern wie GitHub, GitLab und Bitbucket konfiguriert werden. 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 Looker-Entwickler in einem Branch arbeiten können, einer isolierten Version eines Datei-Repositories. Sie können entwickeln und testen, ohne andere Nutzer zu beeinträchtigen. Als Entwickler in Looker verwenden Sie einen Git-Zweig, wenn Sie sich im Entwicklungsmodus befinden.

Ein weiteres wichtiges Merkmal von Git ist die einfache Zusammenarbeit mit anderen Entwicklern. Sie können einen Branch erstellen und (falls gewünscht) Änderungen vornehmen. Andere Entwickler können dann zu diesem Branch wechseln, um ihn zu prüfen oder Änderungen daran vorzunehmen. Wenn ein anderer Entwickler Änderungen am Branch vorgenommen hat, wird in Looker die Schaltfläche Remote-Änderungen abrufen angezeigt. Sie sollten diese Commits in den Branch ziehen, bevor Sie weitere Änderungen vornehmen.

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

Persönliche Zweige

Wenn Sie zum ersten Mal den Entwicklungsmodus aktivieren, wird in Looker automatisch Ihr persönlicher Git-Branch erstellt. Ihr persönlicher Zweig beginnt mit dev- und enthält Ihren Namen.

Ihr persönlicher Branch ist nur für Sie bestimmt und kann nicht gelöscht werden. Ihr persönlicher Branch ist für alle anderen Entwickler nur lesbar. Wenn Sie mit anderen Entwicklern an einem Projekt zusammenarbeiten, können Sie einen neuen Branch erstellen, damit andere zu diesem Branch wechseln und ebenfalls Änderungen vornehmen können.

Neuen Git-Zweig erstellen

Wenn Sie an einer einfachen Fehlerbehebung arbeiten und nicht mit anderen Entwicklern zusammenarbeiten, ist Ihr persönlicher Branch in der Regel ein guter Ort, um zu arbeiten. Sie können mit Ihrem privaten Branch schnell Updates vornehmen, die Änderungen dann committen und in die Produktion pushen.

Es kann jedoch auch sinnvoll sein, zusätzlich zu Ihrem persönlichen Branch neue Git-Branches zu erstellen. In folgenden Fällen ist ein neuer Git-Zweig sinnvoll:

  • Sie arbeiten mit anderen Entwicklern zusammen. Da Ihr persönlicher Branch für andere Entwickler nur lesbar ist, sollten Sie einen neuen Git-Branch erstellen, wenn Sie mit anderen zusammenarbeiten möchten, damit diese Entwickler Änderungen am Branch vornehmen können. Wenn Sie mit anderen zusammenarbeiten, sollten Sie jedes Mal, wenn Sie die Arbeit fortsetzen, die Änderungen abrufen. So haben Sie die neuesten Updates von allen Entwicklern, bevor Sie mit der Arbeit fortfahren.
  • Sie arbeiten an mehreren Funktionen gleichzeitig. Manchmal befinden Sie sich mitten in einem großen Projekt, möchten aber ein kleines Problem beheben oder eine schnelle Lösung finden. In diesem Fall können Sie Ihre Änderungen im aktuellen Branch committen und dann einen anderen Branch erstellen oder zu einem anderen wechseln, um an einer separaten Gruppe von Funktionen zu arbeiten. Sie können die Korrektur im neuen Branch vornehmen und die Änderungen dieses Branches dann in der Produktion bereitstellen, bevor Sie die Arbeit in Ihrem ursprünglichen Branch fortsetzen.

Vor dem Erstellen eines neuen Branches:

  • Wenn in Ihrem aktuellen Branch ein Konflikt beim Zusammenführen vorliegt, müssen Sie ihn beheben, bevor Sie einen neuen Branch erstellen können.
  • Wenn Sie im aktuellen Branch noch nicht committete Änderungen haben, müssen Sie diese festschreiben, bevor Sie einen neuen Branch erstellen.
  • Wenn Sie einen Branch ausgehend von einem vorhandenen Entwicklungszweig (und nicht vom Produktionszweig) erstellen möchten, rufen Sie zuerst die neueste Version des Entwicklungszweigs ab, indem Sie zu diesem Entwicklungszweig wechseln, und ziehen Sie Remote-Änderungen, um Ihre lokale Version dieses Branches zu synchronisieren.

So erstellen Sie einen neuen Git-Branch:

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

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

  3. Wählen Sie im Menü auf der linken Seite das Symbol Git aus, um den Bereich Git-Aktionen zu öffnen.

  4. Öffnen Sie das Drop-down-Menü Filialen ansehen.

  5. Wählen Sie Neuer Zweig aus.

  6. Geben Sie im Fenster Neuer Branch einen Namen für den Branch ein. Für Git-Branch-Namen gelten Einschränkungen. Informationen zu den Benennungsanforderungen finden Sie auf dieser Seite unter Regeln für die Benennung eines Git-Branches.

  7. Wählen Sie im Drop-down-Menü Create From (Aus erstellen) einen vorhandenen Branch aus, der als Ausgangspunkt für den neuen Branch verwendet werden soll.

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

Alternativ können Sie Git-Branches auf dem Tab Branch-Verwaltung in den Einstellungen des Projekts erstellen.

Regeln für die Benennung eines Git-Branches

Looker verwendet die von Git festgelegten Anforderungen an die Benennung von Branches.

Die Namen von Git-Zweigen dürfen nicht:

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

Außerdem kann der Name der Verzweigung nur 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 Verzweigungsnamens interpretiert.

Zu einem anderen Git-Zweig wechseln

Wenn in Ihrem aktuellen Branch ein Konflikt beim Zusammenführen vorliegt, müssen Sie ihn beheben, bevor Sie zu einem anderen Branch wechseln können.

Wenn Sie in Ihrem aktuellen Branch Änderungen vorgenommen haben, die noch nicht festgeschrieben wurden, können Sie erst dann zu einem vorhandenen Branch wechseln, wenn Sie die Änderungen in Ihrem aktuellen Branch festschreiben.

So wechseln Sie zu einem anderen Git-Branch:

  1. Rufen Sie im Projekt den Bereich Git-Aktionen auf, indem Sie im Menü mit den Symbolen links das Symbol Git auswählen.
  2. Wählen Sie im Bereich Git-Aktionen rechts neben dem Namen des aktuellen Git-Branches das Drop-down-Menü für den Git-Branch aus.
  3. Wählen Sie die Branche aus, zu der Sie wechseln möchten, indem Sie sie im Menü auswählen oder den Namen der Branche in das Suchfeld eingeben. Bei der Suche nach Filialnamen wird die Groß- und Kleinschreibung nicht berücksichtigt. Wenn Sie beispielsweise nach „DEV“ suchen, werden alle Branches mit Namen angezeigt, die „dev“, „DEV“ oder „Dev“ enthalten.

Git-Zweige verwalten

Auf dem Tab Branch-Verwaltung der Projekteinstellungen wird eine Tabelle mit allen Git-Branches für das Looker-Projekt angezeigt. Wenn Sie den Tab Branch Management (Zweigstellenverwaltung) öffnen möchten, rufen Sie zuerst die Projekteinstellungen auf, indem Sie im Menü auf der linken Seite das Symbol Einstellungen auswählen. Wählen Sie als Nächstes den Tab Filialverwaltung aus.

Auf dem Tab Filialverwaltung haben Sie folgende Möglichkeiten:

  1. Wählen Sie die Schaltfläche Neuer Zweig aus, um einen neuen Zweig zu erstellen. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Neuen Git-Branch erstellen.
  2. Suche in der Suchleiste nach Filialnamen.
  3. Klicken Sie auf die Schaltfläche Aktualisieren, um die Tabelle zu aktualisieren.
  4. Wählen Sie einen Spaltennamen aus, um die Tabelle zu sortieren.

Die Tabelle enthält die folgenden Informationen:

  • Name: Name des Git-Branches. Die persönlichen Branches von Looker-Entwicklern beginnen mit dev- und enthalten den Vor- und Nachnamen des Entwicklers.
  • Status: Der Unterschied zwischen der lokalen Version des Branches und der Remoteversion des Branches. Ein Status von 3 commits behind bedeutet beispielsweise, dass Ihre lokale Version des Branches drei Commits hinter der Remoteversion des Branches liegt. Da in Looker immer die Remoteversion von „master“ verwendet wird, wird auf dem Tab Branch Management nicht der Status der lokalen Version des Master-Branches angezeigt. Der Master-Branch kann immer als aktuell betrachtet werden.
  • Zuletzt aktualisiert: Zeit, die vergangen ist, seit ein Looker-Entwickler einen Commit für den Branch vorgenommen hat.
  • Aktionen: Eine Schaltfläche zum Löschen des Branches oder der Grund, warum der Branch nicht gelöscht werden kann.

Git-Zweige löschen

Auf dem Tab Filialverwaltung können Sie Filialen löschen, für die in der Tabelle die Schaltfläche Löschen angezeigt wird. Die folgenden Branches können nicht gelöscht werden:

In der Tabelle ist für diese Branches keine Schaltfläche Löschen zu sehen. Stattdessen wird in der Spalte Aktion der Tabelle der Grund angezeigt, warum der Branch nicht gelöscht werden kann.

Gelöschte Branches können nicht wiederhergestellt werden. Wenn Sie einen Branch löschen, entfernt Looker sowohl die lokale Version des Branches als auch die Remoteversion des Branches.

Wenn der Branch jedoch von einem anderen Looker-Entwickler erstellt wurde oder andere Entwickler den Branch herausgecheckt haben, haben diese Entwickler weiterhin ihre lokale Version des Branches. Wenn ein Looker-Entwickler Commits in seiner lokalen Version des Branches vornimmt und ihn in die Produktion überträgt, sehen Sie wieder eine Remote-Version des Branches. Das kann nützlich sein, wenn Sie den Branch wiederherstellen möchten. Andernfalls sollten alle anderen Looker-Entwickler denselben Branch löschen, wenn Sie einen Branch löschen, damit er nicht versehentlich wiederhergestellt werden kann, wenn jemand ihn auf den Remote-Server pusht.

Wenn Sie einen oder mehrere Git-Branches aus Ihrem Projekt löschen möchten, rufen Sie zuerst die Projekteinstellungen auf, indem Sie im Menü auf der linken Seite das Symbol Einstellungen auswählen. Wählen Sie dann den Tab Filialverwaltung aus. Auf dem Tab Filialverwaltung haben Sie zwei Möglichkeiten, Filialen zu löschen:

  1. Wenn Sie mehrere Branches löschen möchten, klicken Sie zuerst auf die Kästchen der Branches und dann auf Ausgewählte Branches löschen.
  2. Wenn Sie einen einzelnen Branch löschen möchten, wählen Sie neben dem Namen des Branches die Option Löschen aus.

Git-Befehle in Looker ausführen

Looker hat eine integrierte Benutzeroberfläche, die sich in Ihren Git-Dienst einbinden lässt. In Looker wird die Git-Schaltfläche rechts oben in der LookML-IDE angezeigt.

Die Git-Schaltfläche zeigt je nach Fortschritt der Änderungen und der Bereitstellung in der Produktion unterschiedliche Optionen an. Im Allgemeinen ist die Option, die auf der Schaltfläche angezeigt wird, der beste Leitfaden für Ihre nächste Aktion.

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

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

Welche Befehle im Bereich Git-Aktionen verfügbar sind, hängt davon ab, in welchem Stadium Sie sich beim Anwenden von Änderungen und beim Bereitstellen in der Produktion befinden.

Änderungen in die Produktion übernehmen

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

Das bedeutet, dass alle Entwickler mit der standardmäßigen Git-Integration ihre Änderungen in einen Branch namens master zusammenführen. Der neueste Commit im master-Branch wird dann für die Produktionsumgebung von Looker verwendet.

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

  • Sie können Ihre Entwickler bitten, Pull-Anfragen für Ihren Git-Produktionszweig einzureichen, anstatt ihnen zu erlauben, ihre Änderungen über die Looker-IDE zusammenzuführen. Weitere Informationen finden Sie auf der Dokumentationsseite Einstellungen für die Versionsverwaltung des Projekts konfigurieren.
  • Im Feld Git-Produktionszweigname können Sie angeben, welchen Zweig aus Ihrem Git-Repository Looker als Zielzweig verwenden soll, in den die Zweige Ihrer Looker-Entwickler zusammengeführt werden. Weitere Informationen finden Sie auf der Dokumentationsseite Einstellungen für die Versionsverwaltung des Projekts konfigurieren.
  • Mit dem erweiterten Bereitstellungsmodus können Sie einen anderen Commit-SHA oder Tag-Namen angeben, der in Ihrer Looker-Produktionsumgebung bereitgestellt werden soll, anstatt den neuesten Commit im Produktionszweig zu verwenden. Wenn Sie einen Commit aus einem anderen Branch bereitstellen möchten, können Sie den erweiterten Bereitstellungsmodus Webhook oder API-Endpunkt 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 Commit ansehen

Die LookML IDE enthält mehrere Indikatoren, die angezeigt werden, wenn Sie sich im Entwicklungsmodus befinden und nicht übernommene Änderungen vorhanden sind. Weitere Informationen finden Sie im Abschnitt Hinzufügungen, Änderungen und Löschungen kennzeichnen der Dokumentationsseite Looker IDE – Übersicht.

Wenn Sie eine Differenzübersicht für alle Dateien aufrufen möchten, wählen Sie im Bereich Git-Aktionen die Option Nicht committete Änderungen ansehen aus.

Im Fenster Nicht übernommene Änderungen am Projekt zeigt Looker eine Zusammenfassung aller nicht übernommenen, gespeicherten Änderungen in allen Projektdateien an. Für jede Änderung werden in Looker folgende Informationen angezeigt:

  • Der Name der ersetzten Datei und der Name der hinzugefügten Datei.
    • Der Name der ersetzten Datei (---) und der Name der hinzugefügten Datei (+++). In vielen Fällen werden hier unterschiedliche Versionen derselben Datei angezeigt, wobei die Änderungen durch --- a/ und +++ b/ gekennzeichnet sind.
    • Gelöschte Dateien werden als Ersatz für eine Nulldatei (+++ /dev/null) angezeigt.
    • Hinzugefügte Dateien werden als Ersatz für eine Nulldatei (--- /dev/null) angezeigt.
  • Die Zeilennummer, an der die Änderung beginnt.

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

Wenn Sie eine Differenzübersicht für eine einzelne Datei anzeigen möchten, wählen Sie im Menü der Datei die Option Änderungen ansehen aus.

Änderungen übernehmen

Nachdem Sie Änderungen an Ihrem LookML-Projekt vorgenommen und gespeichert haben, werden Sie in der IDE möglicherweise aufgefordert, Ihre LookML zu validieren. In diesem Fall wird auf der Git-Schaltfläche der Text LookML validieren angezeigt.

Ob dies erforderlich ist, hängt von der Einstellung für die Codequalität Ihres Projekts ab. Weitere Informationen zum Inhaltsvalidierer finden Sie auf der Seite LookML-Code validieren.

Wenn ein anderer Entwickler seit der letzten Aktualisierung Ihres lokalen Branches Änderungen am Produktionszweig vorgenommen hat, müssen Sie diese Updates aus dem Produktionszweig abrufen. In diesem Szenario wird auf der Git-Schaltfläche der Text Aus der Produktion abrufen angezeigt.

Wenn für Ihr Projekt der erweiterte Bereitstellungsmodus aktiviert ist, wird auf der Git-Schaltfläche stattdessen der Text Pull from Primary Branch (Aus primärem Branch abrufen) angezeigt.

Nachdem Sie Ihre Änderungen gespeichert und gegebenenfalls alle LookML-Warnungen oder -Fehler behoben haben und ggf. Daten aus der Produktion abgerufen haben, wird auf der Git-Schaltfläche der Text Änderungen committen und pushen angezeigt.

Falls gewünscht, können Sie zuerst Ihre nicht übernommenen Änderungen überprüfen, bevor Sie sie übernehmen.

Wenn Sie die Änderungen übernehmen möchten, verwenden Sie die Git-Schaltfläche, um sie in Ihrem aktuellen Branch zu übernehmen. In Looker wird das Dialogfeld Commit angezeigt, in dem die Dateien aufgeführt sind, die hinzugefügt, geändert oder gelöscht wurden.

Geben Sie eine Nachricht ein, in der Sie Ihre Änderungen kurz beschreiben, und entfernen Sie die Häkchen neben allen Dateien, die nicht in die Synchronisierung einbezogen werden sollen. Wählen Sie dann Übernehmen aus, um die Änderungen zu übernehmen.

Nach nicht erstellten PDTs suchen

Wenn Sie Änderungen an PDTs in Ihrem Projekt vorgenommen haben, sollten im Optimalfall alle Ihre PDTs bei der Bereitstellung in der Produktion erstellt sein, damit die Tabellen sofort als Produktionsversionen verwendet werden können. Wenn Sie den Status der PATs im Projekt prüfen möchten, klicken Sie auf das Symbol Projektstatus, um den Bereich Projektstatus zu öffnen, und dann auf die Schaltfläche PDT-Status prüfen.

Weitere Informationen zum Prüfen auf nicht erstellte PDTs 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, mit denen Datentests zur Überprüfung der Logik Ihres LookML-Modells definiert werden. Informationen zum Einrichten von Datentests in Ihrem Projekt finden Sie auf der Seite mit der Parameterdokumentation für test.

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

  1. Wenn in Ihren Projekteinstellungen konfiguriert ist, dass Datentests bestanden werden müssen, bevor Ihre Dateien in der Produktion bereitgestellt werden, wird in der IDE die Schaltfläche Tests ausführen angezeigt, nachdem Sie Änderungen am Projekt commit haben. Dadurch werden alle Tests für Ihr Projekt ausgeführt, unabhängig davon, in welcher Datei der Test definiert ist. Sie müssen die Datentests bestehen, bevor Sie Ihre Änderungen in der Produktion bereitstellen können.
  2. Klicken Sie im Bereich Projektstatus auf die Schaltfläche Datentests ausführen. In Looker werden alle Datentests in Ihrem Projekt ausgeführt, unabhängig davon, in welcher Datei der Test definiert ist.
  3. Wählen Sie im Menü der Datei die Option LookML-Tests ausführen aus. In Looker werden nur die in der aktuellen Datei definierten Tests ausgeführt.

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

  • Ein Datentest ist erfolgreich, wenn die Behauptung des Tests für jede Zeile in der Abfrage des Tests wahr ist. Weitere Informationen zum Einrichten von Testasseverungen und Abfragen finden Sie auf der Seite mit der Parameterdokumentation für test.
  • Wenn ein Datentest fehlschlägt, finden Sie im Bereich Projektstatus Informationen dazu, warum der Test fehlgeschlagen ist, ob beim Test Fehler in der Logik Ihres Modells gefunden wurden oder ob der Test selbst ungültig war.
  • In den Ergebnissen des Datentests können Sie den Namen eines Datentests auswählen, um direkt zur LookML für den Datentest zu gelangen. Sie können auch die Schaltfläche Explore-Abfrage auswählen, um ein Explore mit der im Datentest definierten Abfrage zu öffnen.

In der Produktion bereitstellen

Nachdem Sie Änderungen an Ihrem Branch vorgenommen haben, werden Sie in der Looker IDE aufgefordert, Ihre Änderungen mit dem Hauptzweig zusammenzuführen. Welche Art von Prompt 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 in der IDE aufgefordert, Ihre Änderungen in den Hauptzweig einzubinden. Nachdem Sie Ihren Commit zusammengeführt haben, kann ein Looker-Entwickler mit der Berechtigung deploy Ihren Commit mithilfe des Bereitstellungsmanagers der Looker IDE, eines Webhooks oder eines API-Endpunkts in der Produktion bereitstellen.
  • 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 in der Looker-IDE bei der standardmäßigen Looker-Git-Integration, wenn Sie die Berechtigung deploy haben, aufgefordert, Ihre Änderungen mit dem Produktionszweig zusammenzuführen und in der Produktionsversion Ihrer Looker-Instanz bereitzustellen.

Erweiterter Bereitstellungsmodus

Bei der standardmäßigen Looker-Git-Integration committen Looker-Entwickler ihre Änderungen in ihrem Entwicklungszweig und führen ihn dann mit dem Produktionszweig zusammen. Wenn Sie dann in der Looker-Umgebung bereitstellen, verwendet Looker das neueste Commit im Produktions-Branch. Den Standard-Git-Workflow und andere Optionen für erweiterte Git-Implementierungen finden Sie auf dieser Seite im Abschnitt Änderungen in die Produktion übernehmen.

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

Wenn der erweiterte Bereitstellungsmodus aktiviert ist, werden Entwickler in der Looker-IDE nicht aufgefordert, ihre Änderungen in der Produktion bereitzustellen. Stattdessen werden Entwickler in der IDE aufgefordert, ihre Änderungen in den Produktionszweig einzubinden. Änderungen können dort nur 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 Inhaltsüberprüfung prüfen, ob keine Dashboards oder gespeicherten Looks ungültig geworden sind. Sie haben die Möglichkeit, sie zu korrigieren.

Umgang mit häufigen Problemen

Während der Arbeit an Ihrem Modell müssen Sie möglicherweise Folgendes tun:

  • Änderungen verwerfen

    Gelegentlich möchten Sie die Änderungen an der Datenmodellierung verwerfen. Wenn sie noch nicht gespeichert sind, können Sie die Seite einfach aktualisieren oder verlassen und dann die Warnung akzeptieren. Wenn Sie die Änderungen gespeichert haben, können Sie die nicht bestätigten Änderungen wie im Abschnitt Nicht bestätigte Änderungen rückgängig machen beschrieben rückgängig machen.

  • Merge-Konflikte mit der Arbeit anderer Entwickler beheben

    Wenn mehrere Entwickler an Ihrem Datenmodell arbeiten, kümmert sich Git in der Regel um die Situation. Gelegentlich muss ein Mensch jedoch Zusammenführungskonflikte beheben.

Einige Änderungen, z. B. das Ändern des Namens eines Felds, können sich auf vorhandene Dashboards und Looks auswirken. Wie bereits erwähnt, können Sie nach der Freigabe Ihrer Änderungen für die Organisation die Inhaltsvalidierung verwenden, um Ihre Inhalte zu prüfen und eventuelle Probleme zu beheben.

Änderungen ohne Commit rückgängig machen

Wenn Sie an Ihrem Zweig für die persönliche Entwicklung arbeiten, können Sie nicht committete Änderungen, die Sie gespeichert haben, rückgängig machen, wenn Sie sie nicht bereitstellen möchten. Sie können alle nicht bestätigten Änderungen für alle Dateien im Projekt oder nur 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-Aktionen die Option Zurück zu… aus.
  2. Wählen Sie eine Option zum Zurücksetzen aus:
    • Wenn Sie nur Änderungen ohne Commit rückgängig machen möchten, wählen Sie Änderungen ohne Commit zurücksetzen aus. Sie können auch den Link Änderungen ansehen auswählen, 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 durchgeführten Commit und Commits, wählen Sie Zu Produktionsversion zurückkehren aus.
  3. Wählen Sie Bestätigen aus, um die Rückgängigmachung abzuschließen.

Wenn Sie alle Ergänzungen oder Löschungen im Inhalt einer einzelnen Datei rückgängig machen möchten, wählen Sie im Menü der Datei die Option Änderungen rückgängig machen aus:

Wenn Sie eine Datei umbenennen, löschen Sie im Grunde die Originaldatei und erstellen eine neue Datei mit einem neuen Namen. Da es sich um mehr als eine Datei handelt, können Sie die Umbenennung nicht mit der Option Datei rückgängig machen rückgängig machen. Wenn Sie eine Dateiumbenennung rückgängig machen möchten, verwenden Sie die Option Zurücksetzen auf… im Bereich Git-Aktionen.

Wenn Sie eine Datei gelöscht haben, wird sie im Dateibrowser der IDE nicht mehr angezeigt. Wenn Sie das Löschen einer Datei rückgängig machen möchten, verwenden Sie die Option Zurück zu… im Bereich Git-Aktionen.

Zusammenführungskonflikte lösen

Normalerweise kann Git Ihre neuen Änderungen automatisch mit der Produktionsversion Ihrer LookML-Dateien zusammenführen. Ein Konflikt beim Zusammenführen tritt auf, wenn Git auf widersprüchliche Änderungen stößt und nicht feststellen kann, welche Änderungen beibehalten werden sollen. Das ist in der Regel der Fall, wenn ein anderer Entwickler seit Ihrem letzten Pull Änderungen vorgenommen hat und Sie ebenfalls Änderungen im selben Bereich vorgenommen haben. Wenn in Ihrem Code ein Zusammenführungskonflikt vorliegt, zeigt Looker die Warnung Zusammenführungskonflikte an, nachdem Sie Änderungen committet und aus der Produktion abgerufen haben.

Wenn in Looker die Warnung zu einem Zusammenführungskonflikt angezeigt wird, empfehlen wir Ihnen, den Konflikt zu beheben, bevor Sie weitere Änderungen vornehmen. Wenn Sie einen Zusammenführungskonflikt in die Produktion pushen, kommt es zu Parsefehlern, die die explorative Datenanalyse verhindern können. Wenn Sie ein erfahrener Git-Nutzer sind und die Änderungen pushen möchten, wählen Sie die Schaltfläche Don't Resolve (Nicht beheben) aus.

In der LookML-Datei selbst sind die Zeilen mit Konflikten so gekennzeichnet:

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

In Looker werden die folgenden Zusammenführungsmarkierungen angezeigt, um Zusammenführungskonflikte anzuzeigen:

  • <<<<<<< HEAD kennzeichnet den Beginn der sich überschneidenden Linien.
  • >>>>>>> branch 'master' kennzeichnet das Ende der sich überschneidenden Zeilen.
  • Mit ======= werden die einzelnen Codeversionen voneinander getrennt, damit Sie sie vergleichen können.

Im vorherigen Beispiel steht your code für die von Ihnen gecommitteten Änderungen 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 kennzeichnet diese Dateien rot. Sie können auch in Ihrem Projekt nach Zusammenführungsmarkierungen wie <<<< oder HEAD suchen, um alle Konflikte in Ihrem Projekt zu finden. Sie können betroffene Dateien auch finden, indem Sie in der Zusammenführungswarnung im Bereich Git-Aktionen den Link files auswählen.
  2. Suchen Sie in der Datei die Zeilen mit Zusammenführungskonflikten und löschen Sie die Textversion, die Sie NICHT behalten möchten. Löschen Sie auch alle Markierungen für Zusammenführungskonflikte.

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

  4. Nachdem Sie alle Konfliktbehebungen vorgenommen und alle Zusammenführungsmarkierungen aus Ihrem Projekt gelöscht haben, committen Sie die Änderungen und implementieren Sie sie in der Produktion.

Nachdem Sie den Konflikt bei der Zusammenführung behoben und Ihre Lösung in die Produktion verschoben haben, können andere Entwickler die Produktionsversion abrufen und wie gewohnt weiterarbeiten.

Git-Speicherbereinigung

Die Git-Garbage Collection beseitigt unnötige Dateien und komprimiert Dateiversionen, um Ihr Git-Repository zu optimieren. Die Git-Garbage Collection (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 30 Tage nach der letzten git gc und führt sie dann beim nächsten Neustart aus.git gc

In seltenen Fällen können Sie versuchen, Änderungen an den Remote-Server zu übertragen oder Branch an den Remote-Server zu übertragen, während git gc ausgeführt wird. Wenn in Looker ein Fehler angezeigt wird, warten Sie ein bis zwei Minuten und versuchen Sie es dann noch einmal.