Versionsverwaltung verwenden und bereitstellen

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

Looker kann so konfiguriert werden, dass es mit vielen Git-Anbietern wie GitHub, GitLab und Bitbucket zusammenarbeitet. 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 Zweig arbeiten können, einer isolierten Version eines Datei-Repositorys. 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 Zweig erstellen und bei Bedarf Änderungen vornehmen. Anschließend können andere Entwickler zu diesem Zweig wechseln, um den Zweig zu überprüfen oder zu ändern. 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 Zweig als den Master-Branch, Ihren aktuellen Zweig oder den persönlichen Zweig eines Entwicklers löschen.

Persönliche Zweige

Wenn Sie zum ersten Mal den Entwicklungsmodus aktivieren, erstellt Looker automatisch Ihren persönlichen Git-Branch. Dein persönlicher Zweig beginnt mit dev- und enthält deinen 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 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 Ausgangspunkt. Sie können Ihren persönlichen Zweig verwenden, um schnelle Aktualisierungen vorzunehmen, die Änderungen dann zu übernehmen und in die Produktion zu übertragen.

Es kann jedoch auch sinnvoll sein, zusätzlich zu Ihrem persönlichen Branch neue Git-Branches zu erstellen. Ein neuer Git-Zweig ist in diesen Situationen 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 Änderungen abrufen, wenn Sie die Arbeit fortsetzen. 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 vielleicht 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 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 Zweig vornehmen und die Änderungen dieses Zweigs dann in der Produktion bereitstellen, bevor Sie die Arbeit im ursprünglichen Zweig 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-Zweig:

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

  2. Gehen Sie zu Ihren Projektdateien im Menü Entwickeln.

  3. Wählen Sie im Symbolmenü auf der linken Seite 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 Neuer Zweig aus.

  6. Geben Sie im Fenster Neuer Branch einen Namen für Ihren 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 Zweig zu erstellen.

Alternativ können Sie Git-Zweige auf dem Tab Zweigverwaltung der Projekteinstellungen 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 muss eine öffnende eckige Klammer enthalten: [
  • ein 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 noch nicht übernommene Änderungen haben, können Sie erst dann zu einem vorhandenen Branch wechseln, wenn Sie die Änderungen in Ihrem aktuellen Branch übernommen haben.

Gehen Sie so vor, um zu einem anderen Git-Zweig zu wechseln:

  1. Rufen Sie im Projekt den Bereich Git Actions (Git-Aktionen) auf, indem Sie im Symbolmenü auf der linken Seite das Git-Symbol 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 Zweignamen wird die Groß-/Kleinschreibung nicht berücksichtigt. Sie können beispielsweise nach „DEV“ suchen. Daraufhin werden alle Zweige angezeigt, deren Namen "dev", "DEV", "Dev" usw. enthalten.

Git-Zweige verwalten

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

Auf dem Tab Branch Management (Zweigverwaltung) können Sie Folgendes tun:

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

Die Tabelle enthält die folgenden Informationen:

  • Name: Name des Git-Branches. Looker-Entwickler persönliche Zweige 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 Looker immer die Remote-Version des Masters verwendet, wird auf dem Tab Branch Management nicht der Status der lokalen Version des Master-Branch angezeigt. Der Master-Branch kann immer als aktuell betrachtet werden.
  • Zuletzt aktualisiert: Zeitraum, seit ein Looker-Entwickler einen 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 (Zweigverwaltung) können Sie Zweige löschen, deren Tabelle die Schaltfläche Löschen enthält. Die folgenden Zweige können nicht gelöscht werden:

In der Tabelle gibt es für diese Zweige keine Schaltfläche Löschen. Stattdessen wird in der Spalte Aktion der Tabelle der Grund angezeigt, warum der Branch 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 Ihre lokale Version als auch die Remote-Version des Zweigs.

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 schiebt.

Wenn Sie einen oder mehrere Git-Branches aus Ihrem Projekt löschen möchten, rufen Sie zuerst die Projekteinstellungen auf, indem Sie im Menü mit den Symbolen links das Symbol Einstellungen auswählen. Wählen Sie dann den Tab Branch Management aus. Auf dem Tab Branch Management können Sie Zweige auf zwei Arten löschen:

  1. Löschen Sie mehrere Zweige, indem Sie zuerst die entsprechenden Kästchen und dann Ausgewählte Zweige löschen auswählen.
  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 oben rechts in der LookML-IDE die Git-Schaltfläche 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 Actions verfügbar sind, hängt davon ab, wo Sie gerade Änderungen vornehmen und die Bereitstellung für die Produktion durchführen.

Änderungen an die Produktion übertragen

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 Branch master wird dann 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 Ihre Git-Produktionsverzweigung 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 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 Projektversionsverwaltung konfigurieren.
  • Mit dem erweiterten Bereitstellungsmodus können Sie ein anderes Commit-SHA oder einen anderen Tag-Namen für die Bereitstellung in Ihrer Looker-Produktionsumgebung angeben, anstatt den neuesten Commit im Produktionszweig zu verwenden. Wenn Sie einen Commit aus einem anderen Zweig bereitstellen möchten, können Sie den Webhook oder den 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 Commit ansehen

Die LookML-IDE enthält mehrere Indikatoren, die angezeigt werden, wenn Sie sich im Entwicklungsmodus befinden und Änderungen ohne Commit vorgenommen wurden. Weitere Informationen hierzu finden Sie auf der Dokumentationsseite Looker IDE – Übersicht im Abschnitt Ergänzungen, Änderungen und Löschungen markieren.

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 Keine Commit-Änderungen am Projekt zeigt Looker eine Zusammenfassung aller nicht per Commit durchgeführten, gespeicherten Änderungen in allen Projektdateien 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 (---) 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 so angezeigt, dass sie eine Nulldatei (+++ /dev/null) ersetzen.
    • Hinzugefügte Dateien werden als Ersatz für eine Nulldatei (--- /dev/null) angezeigt.
  • Die Nummer der Zeile, in der die Änderung beginnt.

    -101,4 +101,4 bedeutet beispielsweise, dass in der 101. Zeile der Datei 4 Zeilen entfernt und 4 hinzugefügt wurden. In einer gelöschten Datei mit 20 Zeilen würde -1,20 +0,0 angezeigt werden, wenn in der ersten Zeile der Datei 20 Zeilen entfernt und durch null 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. Auf der Git-Schaltfläche wird in diesem Szenario der Text Validate LookML (LookML validieren) angezeigt.

Ob dies erforderlich ist, hängt von der Einstellung für die Codequalität Ihres Projekts ab. Weitere Informationen zum Content Validator finden Sie auf der Dokumentationsseite zum Validieren Ihres LookML-Codes.

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 alle LookML-Warnungen oder -Fehler falls erforderlich) behoben und ggf. aus der Produktion abgerufen haben (falls erforderlich), zeigt die Git-Schaltfläche den Text Commit Changes & Push.

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

Wenn Sie bereit sind, einen Commit für die Änderungen durchzuführen, verwenden Sie die Git-Schaltfläche, um diese Änderungen in Ihren aktuellen Zweig zu übernehmen. Looker zeigt das Dialogfeld Commit (Commit durchführen) an, 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. Um den Status der PDTs im Projekt zu prüfen, wählen Sie das Symbol Project Health (Projektzustand) aus, 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 zur Suche 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, die Datentests zur Überprüfung der Logik Ihres LookML-Modells definieren. 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, haben Sie mehrere Möglichkeiten, die Datentests Ihres Projekts zu 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 committet haben. Daraufhin 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. 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 in der aktuellen Datei definierten Tests aus.

Nachdem Sie die Datentests ausgeführt haben, werden im Bereich Projektzustand 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, sehen Sie im Bereich Projektzustand Informationen dazu, warum der Test fehlgeschlagen ist, ob dabei Fehler in der Modelllogik gefunden wurden oder ob der Test selbst ungültig war.
  • In den Datentestergebnissen können Sie den Namen eines Datentests auswählen, um direkt zum LookML-Code für den Datentest zu gelangen, oder Sie können die Schaltfläche Explore Query (Abfrage untersuchen) 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. Die Art der Aufforderung, die Sie in der IDE sehen, 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 Ihr Commit zusammengeführt haben, kann ein Looker-Entwickler mit der Berechtigung deploy ihn für die Produktion bereitstellen. Dazu kann er den Deployment Manager der Looker IDE oder einen Webhook oder einen API-Endpunkt verwenden.
  • Wenn Ihr Projekt mithilfe von Pull-Anfragen für die Git-Integration konfiguriert ist, werden Sie aufgefordert, über die Schnittstelle Ihres Git-Anbieters eine Pull-Anfrage zu öffnen.
  • Andernfalls werden Sie bei der standardmäßigen Looker-Git-Integration von der Looker IDE aufgefordert, Ihre Änderungen im Produktionszweig zusammenzuführen und in der Produktionsversion Ihrer Looker-Instanz bereitzustellen, wenn Sie die Berechtigung deploy haben.

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. (Im Abschnitt Änderungen in die Produktion übernehmen auf dieser Seite finden Sie den Standard-Git-Workflow und weitere Optionen für erweiterte Git-Implementierungen.)

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. Dies ist in Entwicklerworkflows 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 in der Produktion bereitgestellt werden.

Wenn der erweiterte Bereitstellungsmodus aktiviert ist, fordert die Looker-IDE Entwickler nicht auf, ihre Änderungen in der Produktion zu implementieren. Stattdessen werden Entwickler in der IDE aufgefordert, ihre Änderungen in den Produktionszweig zusammenzuführen. Von dort aus können Änderungen nur auf die folgenden 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 die Ä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. Falls ja, werden Sie die Möglichkeit haben, sie zu korrigieren.

Umgang mit typischen Problemen

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

  • Änderungen verwerfen

    Es kann vorkommen, dass Sie Ihre Datenmodellierungsänderungen verwerfen möchten. Wenn sie noch nicht gespeichert wurden, können Sie die Seite einfach aktualisieren oder 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ühren von Konflikten mit anderen Entwicklern Arbeit

    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, wie das Ändern des Namens eines Felds, können sich auf vorhandene Dashboards und Looks auswirken. Wie bereits erwähnt, können Sie, nachdem Sie die Änderungen für die Organisation verfügbar gemacht haben, die Inhaltsvalidierung nutzen, um Ihre Inhalte zu überprüfen und Probleme zu beheben.

Änderungen ohne Commit rückgängig machen

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

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 werden.
    • 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.

Um hinzugefügte oder gelöschte Inhalte einer einzelnen Datei rückgängig zu machen, 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 hierbei mehr als eine Datei erforderlich ist, können Sie die Option Datei wiederherstellen nicht verwenden, um die Umbenennung einer Datei rückgängig zu machen. Wenn Sie einen Dateiumbenennung rückgängig machen möchten, verwenden Sie die Option Zurück zu… 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 an die Produktion übertragen, kommt es zu Analysefehlern, die die Analyse Ihrer Daten unter Umständen verhindern. Wenn Sie ein erfahrener Git-Nutzer sind und Änderungen vornehmen möchten, wählen Sie die Schaltfläche Don't Resolve (Nicht auflösen) 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.
  • &gt;&gt;&gt;&gt;&gt;&gt;&gt; branch 'master' markiert das Ende der in Konflikt stehenden 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 im Bereich Git-Aktionen in der Zusammenführungswarnung den Link files auswählen.
  2. Gehen Sie in der Datei zu den Zeilen mit Zusammenführungskonflikten und löschen Sie die Version des Textes, die Sie NICHT behalten möchten. Löschen Sie außerdem 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 nun den Zusammenführungskonflikt gelöst und Ihre Lösung an die Produktion gesendet haben, können andere Entwickler die Produktionsversion nutzen und wie gewohnt weiterarbeiten.

Automatische Git-Bereinigung

Bei der automatischen Speicherbereinigung mit Git werden unnötige Dateien bereinigt und Dateiüberarbeitungen 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 seit dem letzten git gc 30 Tage und führt git gc beim nächsten Neustart aus.

In seltenen Fällen kann es sinnvoll sein, Änderungen per Push an Remote-Server zu übertragen oder Zweig an 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.