Versionsverwaltung verwenden und bereitstellen

Auf dieser Seite wird davon ausgegangen, dass Ihr Projekt bereits für die Versionsverwaltung eingerichtet wurde. Wenn Sie anstelle der auf dieser Seite beschriebenen Optionen die Schaltfläche Configure Git (Git konfigurieren) sehen, 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 Entwickler-Branch einem Git-Branch.

Looker kann für die Zusammenarbeit 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 ist, dass ein Looker-Entwickler in einem Branch arbeiten kann, einer isolierten Version eines Dateirepositorys. 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 Feature 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 Zweig vorgenommen hat, wird in Looker die Schaltfläche Pull Remote Changes (Remote-Änderungen abrufen) angezeigt. Sie sollten diese Änderungen, für die ein Commit durchgeführt wurde, in den Zweig übernehmen, 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

Um die Leistung zu steigern, wird beim ersten Öffnen eines LookML-Projekts im Entwicklermodus die Produktionsmodus-Version des Projekts zusammen mit der Schaltfläche Entwicklerkopie erstellen in der Looker-IDE angezeigt. Wenn Sie für das Projekt auf die Schaltfläche Entwicklerkopie erstellen klicken, erstellt die Looker-IDE Ihren persönlichen Git-Branch und lädt das LookML-Projekt für Sie im Entwicklermodus.

Ihr persönlicher Zweig beginnt mit dev- und enthält Ihren Namen.

Ihr persönlicher Branch ist nur für Sie verfügbar und 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 zusammenarbeiten, sollten Sie möglicherweise einen neuen Branch erstellen, damit andere zu diesem Branch wechseln und ebenfalls Änderungen vornehmen können.

Neuen Git-Branch erstellen

Wenn Sie an einer einfachen Korrektur arbeiten und nicht mit anderen Entwicklern zusammenarbeiten, ist Ihr persönlicher Branch in der Regel ein guter Ort dafür. Sie können Ihren persönlichen Branch verwenden, um schnelle Aktualisierungen vorzunehmen, die Änderungen dann zu committen und in die Produktion zu übertragen.

Möglicherweise möchten Sie aber auch zusätzlich zu Ihrem persönlichen Branch neue Git-Branches erstellen. Ein neuer Git-Zweig ist in folgenden Situationen sinnvoll:

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

Vor dem Erstellen eines neuen Zweigs:

  • Wenn in Ihrem aktuellen Zweig ein Merge-Konflikt vorliegt, müssen Sie diesen Konflikt beheben, bevor Sie einen neuen Zweig erstellen können.
  • Wenn Sie nicht festgeschriebene Änderungen im aktuellen Branch haben, müssen Sie diese festschreiben, bevor Sie einen neuen Branch erstellen.
  • Wenn Sie einen Branch aus einem vorhandenen Entwicklungszweig (und nicht aus dem Produktionszweig) erstellen möchten, rufen Sie zuerst die aktuelle Version des Entwicklungszweigs ab, indem Sie zu diesem Entwicklungszweig wechseln, und ziehen Sie dann Remote-Änderungen, um Ihre lokale Version dieses Zweigs zu synchronisieren.

So erstellen Sie einen neuen Git-Branch:

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

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

  3. Wählen Sie im Symbolmenü 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 Zweig einen Namen für den Zweig ein. Beachten Sie, dass für Git-Branch-Namen Einschränkungen gelten. Informationen zu den Benennungsanforderungen finden Sie auf dieser Seite unter Regeln für die Benennung eines Git-Branch.

  7. Wählen Sie das Drop-down-Menü Create From (Erstellen aus) aus und wählen Sie einen vorhandenen Branch als Ausgangspunkt für Ihren neuen Branch aus.

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

Alternativ können Sie Git-Branches auf dem Tab Branch Management (Branch-Verwaltung) in den Projekteinstellungen erstellen.

Regeln für die Benennung eines Git-Branch

Looker verwendet die von Git festgelegten Anforderungen an die Namenskonvention für Branches.

Git-Zweignamen dürfen nicht:

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

Außerdem darf der Branchname nur dann ein Sternchen (*) enthalten, wenn das Sternchen für eine gesamte Pfadkomponente steht (z. B. foo/* oder bar/*/baz). In diesem Fall wird es als Platzhalter und nicht als Teil des tatsächlichen Branchnamens interpretiert.

Zu einem anderen Git-Zweig wechseln

Wenn in Ihrem aktuellen Branch ein Merge-Konflikt vorliegt, müssen Sie den Konflikt beheben, bevor Sie zu einem anderen Branch wechseln können.

Wenn Sie nicht festgeschriebene Änderungen in Ihrer aktuellen Verzweigung haben, können Sie erst dann zu einer vorhandenen Verzweigung wechseln, wenn Sie die Änderungen in Ihrer aktuellen Verzweigung festschreiben.

So wechseln Sie zu einem anderen Git-Branch:

  1. Rufen Sie im Projekt das Feld Git-Aktionen auf, indem Sie im Symbolmenü links das Symbol Git auswählen.
  2. Wählen Sie im Bereich Git-Aktionen das Drop-down-Menü für den Git-Branch rechts neben dem Namen des aktuellen Git-Branchs aus.
  3. Wählen Sie den Branch aus, zu dem Sie wechseln möchten, indem Sie ihn im Menü auswählen oder den Branch-Namen 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 Namen angezeigt, die „dev“, „DEV“, „Dev“ usw. enthalten.

Git-Zweige verwalten

Auf dem Tab Branch Management (Zweigverwaltung) der Projekteinstellungen wird eine Tabelle mit allen Git-Zweigen für das Looker-Projekt angezeigt. Um den Tab Branch-Verwaltung zu öffnen, rufen Sie zuerst die Projekteinstellungen auf. Klicken Sie dazu im Symbolmenü auf der linken Seite auf das Symbol Einstellungen. Wählen Sie dann den Tab Filialverwaltung aus.

Auf dem Tab Branch-Verwaltung haben Sie folgende Möglichkeiten:

  1. Klicken Sie auf die Schaltfläche Neuer Zweig, um einen neuen Zweig zu erstellen. Weitere Informationen finden Sie auf dieser Seite im Abschnitt Neuen Git-Branch erstellen.
  2. Suchen Sie in der Suchleiste nach Zweignamen.
  3. Aktualisieren Sie die Tabelle, indem Sie auf die Schaltfläche Aktualisieren klicken.
  4. Sie können die Tabelle sortieren, indem Sie einen Spaltennamen auswählen.

Die Tabelle enthält die folgenden Informationen:

  • Name: Name des Git-Branch. Persönliche Branches von Looker-Entwicklern beginnen mit dev- und enthalten den Vor- und Nachnamen des Entwicklers.
  • Status: Der Unterschied zwischen Ihrer lokalen Version des Zweigs und der Remote-Version des Zweigs. Ein Status von 3 commits behind bedeutet beispielsweise, dass Ihre lokale Version des Zweigs drei Commits hinter der Remoteversion des Zweigs liegt. Da Looker immer die Remote-Version von „master“ verwendet, wird auf dem Tab Branch Management (Zweigverwaltung) nicht der Status der lokalen Version des Master-Zweigs angezeigt. Der Master-Branch ist immer aktuell.
  • Zuletzt aktualisiert: Die Zeit, die seit dem letzten Commit eines Looker-Entwicklers für den Branch vergangen ist.
  • 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 (Branch-Verwaltung) können Sie Branches löschen, für die in der Tabelle die Schaltfläche Delete (Löschen) angezeigt wird. Die folgenden Zweige können nicht gelöscht werden:

In der Tabelle ist für diese Zweige keine Schaltfläche Löschen vorhanden. Stattdessen wird in der Spalte Aktion der Tabelle der Grund dafür angezeigt, dass 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 als auch die Remote-Version des Branch.

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

Wenn Sie einen oder mehrere Git-Branches aus Ihrem Projekt löschen möchten, rufen Sie zuerst die Projekteinstellungen auf. Klicken Sie dazu im Symbolmenü auf der linken Seite auf das Symbol Einstellungen. Wählen Sie dann den Tab Filialverwaltung aus. Auf dem Tab Branch Management (Branch-Verwaltung) haben Sie zwei Möglichkeiten, Branches zu löschen:

  1. Wenn Sie mehrere Zweige löschen möchten, wählen Sie zuerst die entsprechenden Kästchen aus und dann Ausgewählte Zweige löschen.
  2. Wenn Sie einen einzelnen Branch löschen möchten, wählen Sie neben dem Branch-Namen Löschen aus.

Git-Befehle in Looker ausführen

Looker hat eine integrierte Schnittstelle, die in Ihren Git-Dienst eingebunden wird. In Looker wird die Git-Schaltfläche oben rechts in der LookML IDE angezeigt.

Die Git-Schaltfläche bietet je nach Phase des Änderungs- und Bereitstellungsprozesses unterschiedliche Optionen. Im Allgemeinen ist die Option auf der Schaltfläche 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 Aktuell angezeigt und sie kann nicht ausgewählt werden.

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

Die im Bereich Git Actions verfügbaren Befehle hängen davon ab, an welcher Stelle des Prozesses Sie sich befinden, Änderungen vorzunehmen und in der Produktionsumgebung bereitzustellen.

Änderungen in der Produktion bereitstellen

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

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

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

  • Sie können Ihre Entwickler Pull-Anfragen für Ihren Git-Produktionszweig senden lassen, 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.
  • Mit dem Feld Git Production Branch Name (Name des Git-Produktionszweigs) können Sie angeben, welcher Zweig aus Ihrem Git-Repository von Looker als Zielzweig verwendet werden 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.
  • Im erweiterten Bereitstellungsmodus können Sie einen anderen Commit-SHA oder Tag-Namen für die Bereitstellung in Ihrer Looker-Produktionsumgebung angeben, anstatt den letzten 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 Sie anstelle der in diesem Abschnitt beschriebenen Optionen die Schaltfläche Configure Git (Git konfigurieren) sehen, müssen Sie zuerst Git für Ihr Projekt einrichten.

Änderungen ohne durchgeführten Commit ansehen

Die LookML-IDE enthält mehrere Indikatoren, die angezeigt werden, wenn Sie sich im Entwicklermodus befinden und nicht übertragene Änderungen haben. Diese werden im Abschnitt Hinzufügungen, Änderungen und Löschungen markieren auf der Dokumentationsseite Looker-IDE – Übersicht beschrieben.

Sie können eine Zusammenfassung der Unterschiede für alle Dateien abrufen, indem Sie im Bereich Git-Aktionen die Option Nicht übertragene Änderungen ansehen auswählen.

Im Fenster Uncommitted Changes to Project (Nicht übertragene Änderungen am Projekt) wird eine Zusammenfassung aller nicht übertragenen, gespeicherten Änderungen in allen Projektdateien angezeigt. Für jede Änderung wird in Looker Folgendes angezeigt:

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

    Beispiel: -101,4 +101,4 bedeutet, dass in der 101. Zeile der Datei 4 Zeilen entfernt und 4 Zeilen hinzugefügt wurden. Bei einer gelöschten Datei mit 20 Zeilen würde -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 Zeilen werden rot dargestellt.
    • Hinzugefügte Zeilen werden grün angezeigt.

Wenn Sie eine Zusammenfassung der Unterschiede für eine einzelne Datei aufrufen 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, müssen Sie möglicherweise Ihr LookML in der IDE validieren. Auf der Git-Schaltfläche wird in diesem Fall der Text LookML validieren angezeigt.

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

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

Wenn Ihr Projekt für den erweiterten Bereitstellungsmodus aktiviert ist, wird auf der Git-Schaltfläche stattdessen der Text Aus primärem Branch pullen angezeigt.

Nachdem Sie Ihre Änderungen gespeichert und alle LookML-Warnungen oder ‑Fehler behoben haben (falls erforderlich) und die Änderungen aus der Produktionsumgebung abgerufen haben (falls erforderlich), wird auf der Git-Schaltfläche der Text Commit Changes & Push (Änderungen committen und per Push übertragen) angezeigt.

Bei Bedarf können Sie sich Ihre nicht übernommenen Änderungen ansehen, bevor Sie sie übernehmen.

Wenn Sie die Änderungen übernehmen möchten, verwenden Sie die Git-Schaltfläche, um die Änderungen für den aktuellen Zweig 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 synchronisiert werden sollen. Wählen Sie dann Commit 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 von PATs im Projekt prüfen möchten, wählen Sie das Symbol Projektstatus aus, um das Steuerfeld Projektstatus zu öffnen, und klicken Sie dann auf die Schaltfläche PAT-Status validieren.

Weitere Informationen zum Suchen nach nicht erstellten 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 definiert werden, um die Logik Ihres LookML-Modells zu prüfen. Informationen zum Einrichten von Datentests in Ihrem Projekt finden Sie auf der Dokumentationsseite zum Parameter test.

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

  1. Wenn Ihre Projekteinstellungen so konfiguriert sind, 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 übertragen haben. So können Sie alle Tests für Ihr Projekt ausführen, 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. Looker führt alle Datentests in Ihrem Projekt aus, 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. Looker führt nur die Tests aus, die in der aktuellen Datei definiert sind.

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

  • Ein Datentest ist erfolgreich, wenn die Assertion des Tests für jede Zeile in der Abfrage des Tests zutrifft. Weitere Informationen zum Einrichten von Test-Assertions und ‑Abfragen finden Sie auf der Dokumentationsseite zum Parameter test.
  • Wenn ein Datentest fehlschlägt, enthält der Bereich Projektstatus Informationen dazu, warum der Test fehlgeschlagen ist, ob im Modell Fehler in der Logik 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 zum LookML für den Datentest zu gelangen. Alternativ können Sie auf die Schaltfläche Explore-Abfrage klicken, um ein Explore mit der im Datentest definierten Abfrage zu öffnen.

In der Produktion bereitstellen

Nachdem Sie Änderungen an Ihrem Zweig vorgenommen haben, werden Sie in der Looker-IDE aufgefordert, die Änderungen mit dem primären Zweig 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 primären Branch zu übernehmen. Sobald Sie Ihren Commit zusammengeführt haben, kann ein Looker-Entwickler mit der Berechtigung deploy Ihren Commit in der Produktion bereitstellen. Dazu kann er den Bereitstellungsmanager in der Looker-IDE, einen Webhook oder einen API-Endpunkt verwenden.
  • Wenn Ihr Projekt für die Git-Integration mit Pull-Anfragen konfiguriert ist, werden Sie aufgefordert, eine Pull-Anfrage über die Schnittstelle Ihres Git-Anbieters zu öffnen.
  • Andernfalls werden Sie bei der standardmäßigen Looker-Git-Integration mit der Berechtigung deploy in der Looker-IDE aufgefordert, Ihre Änderungen in den Produktionszweig zusammenzuführen und in der Produktionsversion Ihrer Looker-Instanz bereitzustellen.

Erweiterter Bereitstellungsmodus

Bei der standardmäßigen Looker-Git-Integration führen Looker-Entwickler ihre Änderungen im Entwicklungszweig per Commit aus und führen den Entwicklungszweig dann mit dem Produktionszweig zusammen. Wenn Sie dann in der Looker-Umgebung bereitstellen, verwendet Looker den letzten Commit im Produktions-Branch. Informationen zum Standard-Git-Workflow und zu anderen Optionen für erweiterte Git-Implementierungen finden Sie auf dieser Seite im Abschnitt Änderungen in der Produktion bereitstellen.

In Fällen, in denen Sie nicht immer den neuesten Commit im Produktionszweig für Ihre Looker-Umgebung verwenden möchten, kann ein Entwickler mit der Berechtigung deploy den erweiterten Bereitstellungsmodus verwenden, um den genauen Commit für Ihre Looker-Umgebung anzugeben. Das ist nützlich in Entwickler-Workflows mit mehreren Umgebungen, in 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 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 mit dem Produktionszweig zusammenzuführen. Änderungen können nur auf folgende Weise 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 die Änderungen für die Organisation verfügbar gemacht haben, können Sie die Inhaltsvalidierung verwenden, um sicherzustellen, dass Sie keine Dashboards oder gespeicherten Looks ungültig gemacht haben. Sie haben dann die Möglichkeit, die Probleme zu beheben.

Typische Probleme beheben

Während Sie an Ihrem Modell arbeiten, müssen Sie möglicherweise Folgendes tun:

  • Änderungen verwerfen

    Manchmal möchten Sie Ihre Änderungen am Datenmodell 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 Änderungen ohne durchgeführten Commit wie im Abschnitt Änderungen ohne durchgeführten Commit rückgängig machen beschrieben rückgängig machen.

  • Merge-Konflikte mit der Arbeit anderer Entwickler beheben

    Wenn mehrere Entwickler an Ihrem Datenmodell arbeiten, wird die Situation in der Regel von Git gehandhabt. Gelegentlich muss jedoch ein Mensch 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 Bereitstellung Ihrer Änderungen für die Organisation die Inhaltsvalidierung verwenden, um Ihre Inhalte zu prüfen und eventuelle Probleme zu beheben.

Änderungen ohne durchgeführten Commit zurücksetzen

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

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

  1. Wählen Sie im Bereich Git Actions die Option Revert to... aus.
  2. Wählen Sie eine Option zum Rückgängigmachen aus:
    • Wenn Sie nur Änderungen ohne durchgeführten Commit zurücksetzen möchten, wählen Sie Änderungen ohne durchgeführten Commit zurücksetzen aus. Sie können auch auf den Link Änderungen ansehen klicken, um die Änderungen zu sehen, die rückgängig gemacht werden.
    • Wenn Sie alle Änderungen, einschließlich der Änderungen ohne durchgeführten Commit und der Änderungen mit durchgeführten Commit, rückgängig machen möchten, wählen Sie Zurücksetzen auf Produktion aus.
  3. Wähle Bestätigen aus, um den Vorgang abzuschließen.

Wenn Sie 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 Option Datei zurücksetzen nicht verwenden, um das Umbenennen einer Datei rückgängig zu machen. Wenn Sie das Umbenennen einer Datei rückgängig machen möchten, verwenden Sie im Bereich Git-Aktionen die Option Zurücksetzen auf….

Wenn Sie eine Datei gelöscht haben, wird sie auch nicht mehr im Dateibrowser der IDE angezeigt. Wenn Sie das Löschen einer Datei rückgängig machen möchten, verwenden Sie im Bereich Git Actions die Option Revert to....

Zusammenführungskonflikte lösen

In der Regel kann Git Ihre neuen Änderungen automatisch mit der Produktionsversion Ihrer LookML-Dateien zusammenführen. Ein Merge-Konflikt tritt auf, wenn Git auf widersprüchliche Änderungen stößt und nicht erkennen kann, welche Änderungen beibehalten werden sollen. Das ist in der Regel der Fall, wenn ein anderer Entwickler Änderungen vorgenommen hat, seit Sie das letzte Mal einen Pull durchgeführt haben, und Sie Änderungen im selben Bereich vorgenommen haben. Wenn Sie einen Merge-Konflikt in Ihrem Code haben, wird in Looker nach dem Committen von Änderungen und dem Pull aus der Produktion die Warnung Merge-Konflikte angezeigt.

Wenn in Looker die Warnung zu einem Merge-Konflikt angezeigt wird, empfehlen wir, den Merge-Konflikt zu beheben, bevor Sie weitere Änderungen vornehmen. Wenn Sie einen Merge-Konflikt in die Produktion übertragen, führt das zu Parsing-Fehlern, die die explorative Datenanalyse verhindern können. Wenn Sie ein erfahrener Git-Nutzer sind und Änderungen pushen möchten, wählen Sie die Schaltfläche 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 auf Zusammenführungskonflikte hinzuweisen:

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

Im vorherigen Beispiel stellt your code die Änderungen dar, die Sie committet haben, und production code 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. Sie können auch in Ihrem Projekt nach Merge-Markierungen suchen, z. B. <<<< oder HEAD, um alle Konflikte in Ihrem Projekt zu finden. Sie können betroffene Dateien auch finden, indem Sie im Bereich Git-Aktionen in der Merge-Warnung auf den Link Dateien klicken.
  2. Suchen Sie in der Datei nach den 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 Zusammenführungskonflikten gekennzeichnet sind.

  4. Nachdem Sie alle Merge-Konflikte behoben und alle Merge-Markierungen aus Ihrem Projekt gelöscht haben, übernehmen Sie die Änderungen und stellen Sie sie in der Produktion bereit.

Nachdem Sie den Merge-Konflikt behoben und die Lösung in die Produktionsumgebung übertragen haben, können andere Entwickler die Änderungen aus der Produktionsumgebung abrufen und wie gewohnt weiterarbeiten.

Automatische Speicherbereinigung in Git

Bei der Git-Garbage Collection werden unnötige Dateien entfernt und Dateirevisionen komprimiert, 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 dem letzten git gc und führt git gc dann beim nächsten Neustart aus.

In seltenen Fällen versuchen Sie möglicherweise, Änderungen per Push an das Remote-Repository zu übertragen oder Branch per Push an das Remote-Repository zu übertragen, während git gc ausgeführt wird. Wenn in Looker ein Fehler angezeigt wird, warten Sie ein oder zwei Minuten und versuchen Sie dann noch einmal, die Änderungen zu übertragen.