Power BI Source Control; die Git-Integration kommt zu einem Arbeitsbereich in Ihrer Nähe!

Möchten Sie mehr über Git und/oder Power BI erfahren?

Informieren Sie sich über unsere Git-Kurse hier und unsere Power BI-Kurse hier !

Einführung

Sie setzen sich hin, machen sich eine Tasse Kaffee und beschließen in einem Anfall von Enthusiasmus, Ihren Power BI-Bericht zu überarbeiten: Das können wir besser. Die ersten Änderungen funktionieren zwar nicht auf Anhieb wie gewünscht, aber die Ergebnisse sind ermutigend. Sie optimieren hier eine Kennzahl, dort eine Grafik, und die Dopaminschübe der Problemlösung halten Sie auf Trab. Dann wird es Ihnen plötzlich klar: Dieses Kaninchenloch war tiefer als erwartet und nach über einer Stunde Arbeit sind Sie Ihrem Ziel nicht näher gekommen als zu Beginn. Vielmehr ist Ihr DAX jetzt ein einziges Durcheinander. Ein mulmiges Gefühl stellt sich ein, denn die Grafik ist kaputt und ... kein Backup.

Kommt Ihnen das bekannt vor?

Dieser Blog ist für alle, die genau dieses Szenario durchlebt haben oder ihm beängstigend nahe gekommen sind. Wir präsentieren Ihnen die Lösung: Die Verwendung der Versionskontrolle mit Power BI. Sie ermöglicht es allen Nutzern, kostenlos zu experimentieren und Änderungen zu verwalten, ohne dass das Chaos ausbricht. Lassen Sie uns darüber sprechen, was es bedeutet, warum es wichtig ist und wie Sie damit anfangen können.

Das Was und Warum der Quellcodekontrolle

Mit der Versionskontrolle können Sie Änderungen an Dateien verfolgen und verwalten. Sie macht es besonders einfach, mit einem Team an der gleichen Datei zusammenzuarbeiten. Der Begriff Versionskontrolle ist zum Synonym für Git geworden. Git ist das wichtigste Tool für die nahtlose Kompilierung und Integration von Änderungen, die verschiedene Benutzer an demselben Code vornehmen möchten. Außerdem lässt sich mit Git die Historie der Änderungen verfolgen. Sie sehen, worauf das hinausläuft? Sie können jederzeit zu einer früheren Version zurückkehren, wenn Ihnen ein lästiger Fehler durch die Lappen gegangen ist.

Git lässt sich jetzt in Power BI integrieren, dessen Berichte ebenfalls nur aus Codesammlungen bestehen. Allerdings ist es nicht ganz einfach, diesen Code ausfindig zu machen. Power BI stützt sich traditionell auf .pbix-Dateien. Wenn zwei Personen dieselbe .pbix-Datei bearbeiten, gibt es keine einfache Möglichkeit, Änderungen zu vergleichen, Konflikte zu lösen oder überhaupt zu verstehen, was sich geändert hat. Nicht ganz das Ergebnis, nach dem wir suchen ...

Geben Sie .pbip (Power BI Project) Dateien ein. Wenn Sie einen Bericht im Format .pbip speichern, speichert Power BI jedes Element als JSON und erstellt zwei Ordner: einen .Report und einen .SemanticModel. Ersterer enthält den gesamten Code für die Visuals, Seiten und Metadaten und letzterer den gesamten Code für den Datensatz, wie Tabellen, Kennzahlen und Beziehungen (siehe Schritt 2 für ein visuelles Beispiel). Darüber hinaus hat Microsoft die Tabular Model Definition Language (.tmdl) eingeführt, um das Modell in separate Objekte aufzuteilen, so dass Sie statt eines einzigen großen JSON-Ordners möglicherweise einen Ordner mit separaten Dateien für z.B. jede Tabelle haben. Das heißt, wenn Sie eine DAX-Kennzahl ändern oder eine neue berechnete Spalte hinzufügen, ändert sich nur dieser spezielle Teil, und Git wird genau diesen Unterschied hervorheben.

Durch die Kombination von Git-Integration, .pbip und .tmdl können Ihre Datensätze, Kennzahlen, Beziehungen und visuellen Darstellungen als strukturierter Text vorliegen, der lesbar und nachvollziehbar ist.

So verbessert die Versionskontrolle den Workflow von Power BI und ermöglicht eine sorgenfreie Entwicklung. Dies zahlt sich besonders aus, wenn Sie von der Einzelentwicklung zur Zusammenarbeit übergehen. Ein Team von BI-Entwicklern kann nun parallel nach Herzenslust am selben Dashboard arbeiten! Lassen Sie uns herausfinden, wie Sie es einrichten können.

Einrichten von Power BI Source Control (Schritt für Schritt)

Nun zum praktischen Teil. Wie implementieren Sie das eigentlich? In diesem Abschnitt geben wir Ihnen eine detaillierte Anleitung für die Einrichtung von Power BI mit Git-Quellcodekontrolle. Wir gehen davon aus, dass Sie mit den Konzepten von Git (Commit, Push, Branch usw.) vertraut sind, aber selbst wenn nicht, werden wir die notwendigen Schritte im Zusammenhang erklären. Wenn Sie noch mehr über Git erfahren möchten, verweisen wir Sie auf diesen Blog oder schauen Sie sich unseren Kurs zu besuchen.

Lassen Sie uns erst einmal bei Null anfangen:

Voraussetzungen

Bevor wir richtig loslegen können, müssen noch einige Dinge erledigt werden.

Schritt 1: Vorbereiten oder Klonen eines Git-Repositorys

Sobald Sie diese Voraussetzungen erfüllt haben, können wir mit dem Klonen unseres Git-Repositorys beginnen. Entscheiden Sie zunächst, wo sich Ihr Power BI-Projekt in der Versionskontrolle befinden soll:

Zur Veranschaulichung nehmen wir an, wir haben ein neues GitHub-Repositorium namens PowerBI-SalesAnalysis. Wir klonen es nach C:\Repos\PowerBI-SalesAnalysis. Zu Beginn ist dieser Ordner möglicherweise leer (außer vielleicht einer README oder .gitignore).

Tipp: Wenn Sie ein neues Projektarchiv für ein Power BI-Projekt erstellen, möchten Sie vielleicht eine .gitignore (Textdatei, die Git mitteilt, welche Dateien ignoriert werden sollen) hinzufügen. Power BI Desktop hilft Ihnen jedoch dabei, indem es beim Speichern eines Projekts eine generiert, die Cache- und lokale Einstellungsdateien automatisch ignoriert. Wir werden das bald behandeln.

Schritt 2: Speichern Sie Ihre Power BI-Datei als Projekt (.pbip)

Lassen Sie uns nun Ihre Power BI-Inhalte im neuen Format in dieses Repository übertragen:

Power BI Desktop wird einen Ordner unter diesem Verzeichnis erstellen. Wenn Sie zum Beispiel SalesAnalysis.pbip unter C:\Repos\PowerBI-SalesAnalysis gespeichert haben, enthält der Ordner nun Folgendes:

Wenn Sie nun VS Code (oder Ihren Datei-Explorer) aufrufen, sollten Sie die Dateien sehen. In VS Code würde es jetzt etwa so aussehen:

REPOS
├── SalesAnalysis.Report

│   ├── report.json

│   ├── ... (Here you may have other folders, such as CustomVisuals)

│   └── semanticModelDiagramLayout.json

├── SalesAnalysis.SemanticModel

│   ├── definition\\ ... (containing tables, cultures, roles, expressions, model and relationships)

│   ├── diagramLayout.json

├── .gitignore

└── SalesAnalysis.pbip

(ein aktuelles Beispiel für die vom .pbip-Dateiformat erzeugte Ordnerstruktur)

Die .pbip-Datei ist das, was Sie in Power BI öffnen, um das Projekt zu laden. Aber in der Versionskontrolle sind die Ordner mit den JSON/TMDL-Dateien die wichtigen Teile. Werfen Sie zum Beispiel einen Blick auf die JSON-Dateien. Machen Sie sich keine Sorgen, wenn sie kompliziert aussehen; der Punkt ist, dass sie aus Text bestehen und versioniert werden können.

Schritt 3: Initialisieren Sie Git (falls noch nicht geschehen) und führen Sie einen ersten Commit durch.

Haben Sie ein leeres Repository neu geklont? Dann müssen Sie es mit dem Befehl git init initialisieren. Wenn Sie jedoch von einem bestehenden Remote-Repository geklont haben, ist Git in diesem Ordner bereits initialisiert. Jetzt kommt es darauf an, die Dateien Ihres neuen Power BI-Projekts zu übertragen:

Herzlichen Glückwunsch, Ihr Power BI-Bericht ist jetzt unter Quellcodekontrolle! Von nun an werden alle Änderungen, die Sie in Power BI vornehmen (und speichern), zu Änderungen an diesen Dateien führen, die Sie festschreiben und schließlich auf Ihr Remote-System übertragen können, damit sie von anderen genutzt werden können, worauf wir jetzt eingehen.

Schritt 4: Zusammenarbeiten!

Apropos andere: Wenn Sie mit einem Team zusammenarbeiten, ist die Verwendung von Zweigen eine gute Praxis. Sie werden wahrscheinlich einen Hauptzweig haben, der die geprüfte und stabile Version Ihres Berichts darstellt. Von hier aus können wir weitere Funktionszweige für die Entwicklungsarbeit erstellen. Ich sage Ihnen, wie!

Nehmen wir an, der Standardzweig unseres Repositorys ist main (der jetzt unseren ersten Commit enthält). Für eine neue Funktion oder Änderung, die Sie entwickeln möchten, sollten Sie ein paar Schritte befolgen:

Sie wissen nicht genau, wie Sie nach dem Commit pushen müssen? Folgen Sie einfach den Abbildungen unten und klicken Sie schließlich auf Zweig veröffentlichen. Ihr neuer Zweig und Ihre neue Funktion befinden sich nun in Ihrem entfernten Repository, wo andere sie überprüfen und schließlich in den Hauptzweig einfügen können, von dem aus Sie neue Zweige für andere Funktionen erstellen können.

(Schritt 1. Unten links zeigt an, in welchem Zweig wir uns befinden - es ist der Hauptzweig!)

(Schritt 1. Wenn Sie auf diesen Zweig klicken, öffnet sich das Menü zum Auschecken oder Erstellen anderer Zweige. Ich werde einen neuen Zweig mit dem Namen 'feature/add-new-measures' erstellen)

(Schritt 2. Ich habe meinen Bericht SalesAnalysis.pbip geöffnet und ein neues Measure 'My new measure to demo git' erstellt und gespeichert. Haben Sie bemerkt, dass VS Code eine Änderung an meiner Measure-Tabelle '0a_Measures.tmdl' in Grün vorgenommen hat? Unten links sehen Sie außerdem, dass ich jetzt an meinem feature/add-new-measures-Zweig arbeite. Es sieht so aus, als würde die Git-Integration funktionieren).

(Schritt 2. Das Öffnen des Bereichs 'Versionskontrolle' auf der linken Seite bestätigt, dass vier Änderungen vorgenommen wurden, vor allem an 0a_Measures.tmdl. Ich habe also alle diese Änderungen übernommen und eine Commit-Nachricht geschrieben. Drücken Sie einfach auf 'Commit').

(Schritt 3. Beinahe fertig. Klicken Sie auf 'Zweig veröffentlichen' und er wird in Ihrem entfernten Repository veröffentlicht)

(Schritt 4. Aufregend! Schauen Sie sich das entfernte Repository an. Oben sehen Sie das 'feature/add-new-measures' und unten sehen Sie den Inhalt, einschließlich meines neuen Commits.)

Lassen Sie uns das alles zusammenfassen. Im Alltag sieht die Verwendung von Power BI mit Source Control folgendermaßen aus:

Fazit

Die Git-Integration von Power BI und das .pbip-Projektformat markieren einen Wendepunkt in der BI-Entwicklung. Vorbei ist der wilde Westen der Dateien in der Art von "_v2_final_final". Wir haben jetzt einen strukturierten, teamfreundlichen Prozess zur Verfügung. Wenn Sie sich diesen Prozess zu eigen machen, erhalten Sie alle Vorteile eines Softwareentwicklungs-Workflows: Transparenz, Verantwortlichkeit, Zusammenarbeit und Sicherheitsnetze.

Im Alltag bedeutet das, dass Sie keine Angst mehr haben müssen, etwas unwiderruflich kaputt zu machen. Wenn eine Änderung nicht funktioniert, können Sie einfach zu einer früheren Version zurückkehren! Auch das Experimentieren im Tandem stellt kein Problem mehr dar. Zweigen Sie einfach ab, heben Sie ab und liefern Sie ein besseres Produkt!

Viel Spaß beim Berichten und beim Versionieren! 🎉

Danke fürs Lesen! Ich hoffe, dies war hilfreich. Haben Sie noch Fragen? Sie können mich gerne kontaktieren hier