Planung der Power BI-Implementierung: Entwickeln von Inhalten und Verwalten von Änderungen

Hinweis

Dieser Artikel ist Teil der Power BI-Implementierungsplanungsreihe von Artikeln. Die Serie konzentriert sich auf die Planung einer Power BI-Erfahrung in Microsoft Fabric. Weitere Informationen finden Sie in der Einführung der Reihe.

Dieser Artikel hilft Ihnen, Inhalte zu entwickeln und Änderungen im Rahmen der Verwaltung des Inhaltslebenszyklus zu verwalten. Er wendet sich in erster Linie an folgende Zielgruppen:

• Center of Excellence (COE) und BI-Teams: Die Teams, die für die Überwachung von Power BI in der Organisation verantwortlich sind. Zu diesen Teams gehören Entscheidungsträger, die entscheiden, wie der Lebenszyklus von Power BI-Inhalten verwaltet werden soll. Diese Teams können auch Rollen wie Releasemanager enthalten, die den Lebenszyklus von Inhaltsveröffentlichungen behandeln, oder Techniker, die die komponenten erstellen und verwalten, die für die effektive Nutzung und Unterstützung der Lebenszyklusverwaltung erforderlich sind.
• Inhaltsersteller und Inhaltsbesitzer: Benutzer, die Inhalte erstellen, die sie im Fabric-Portal veröffentlichen möchten, um sie für andere Personen freizugeben. Diese Personen sind für die Verwaltung des Lebenszyklus der von ihnen erstellten Power BI-Inhalte verantwortlich.

Das Lebenszyklusmanagement sind die Prozesse und Methoden, die Sie nutzen, um Inhalte von ihrer Erstellung bis zu ihrer endgültigen Ausmusterung zu behandeln. In der ersten Phase des Lebenszyklusmanagements planen und entwerfen Sie Inhalte, die die Lösungsplanung und die Entscheidungsfindung betreffen, die sich auf Ihren Ansatz zur Lebenszyklusverwaltung auswirken. In der zweiten Phase entwickeln Sie Inhalte und verwalten Änderungen.

Das Verwalten von Inhaltsänderungen während des Lebenszyklus ist wichtig, um eine effektive Zusammenarbeit zwischen Inhaltserstellern und einer stabilen und konsistenten Bereitstellung von Inhalten für Verbraucher sicherzustellen.

Die folgende Abbildung zeigt den Lebenszyklus von Power BI-Inhalten, wobei Phase 2 hervorgehoben wird, in der Sie Inhalte entwickeln und Änderungen verwalten.

Hinweis

Eine Übersicht über die Lebenszyklusverwaltung von Inhalten finden Sie im ersten Artikel dieser Reihe.

Tipp

Dieser Artikel konzentriert sich auf wichtige Entscheidungen und Überlegungen, mit denen Sie Inhalte entwickeln und Änderungen während des gesamten Lebenszyklus verwalten können. Weitere Anleitungen zum Entwickeln von Inhalten und Verwalten von Änderungen finden Sie unter:

• Was ist die Lebenszyklusverwaltung in Microsoft Fabric?: Dieser Artikel enthält eine technische Einführung und ein Lernprogramm zu Fabric Git-Integrations- und Bereitstellungspipelines.
• Bewährte Methoden für die Lebenszyklusverwaltung: Dieser Artikel enthält praktische Tipps und Anleitungen für die Verwendung der Lebenszyklusverwaltungsfeatures von Fabric und Power BI zum Entwickeln von Inhalten und Verwalten von Änderungen.
• Power BI Desktop OneDrive und SharePoint-Integration: Dieser Artikel enthält eine Übersicht über die Optionen zum Verwenden und Speichern von Dateien, die auf OneDrive für Arbeit und Schule oder SharePoint gespeichert sind, wenn Sie die Versionssteuerung mit PBIX-Dateien ausführen.
• Erste Schritte mit Git in Azure Repos: Diese Artikelreihe enthält praktische Tipps, Lernprogramme und Anleitungen zum Ausführen der Quellcodeverwaltung mithilfe eines Git-Repositorys in Azure Repos.

Inhaltsersteller und Besitzer sollten Inhaltsänderungen mithilfe der Versionssteuerung verwalten. Die Versionskontrolle ist die Methode zum Verwalten von Änderungen an Dateien oder Code in einem zentralen Repository. Diese Praxis erleichtert eine effektivere Zusammenarbeit und Content Management.

Weitere Vorteile der Versionssteuerung sind folgende:

• Änderungen von mehreren Inhaltserstellern zusammenführen und Zusammenführungskonflikte bewältigen.
• Identifizieren Sie, welche Inhalte geändert wurden und welche Änderungen in diesem Inhalt vorgenommen wurden.
• Verknüpfen von Inhaltsänderungen mit bestimmten Arbeitsaufgaben.
• Änderungen in eigenständige Releases mit Versionsverlauf gruppieren.
• Zurücksetzen von Änderungen oder ganzen Versionen von Inhalten

Tipp

Es wird empfohlen, die Versionssteuerung für alle Inhalte zu verwenden, die Sie erstellen, sofern möglich. Die Verwendung der Versionssteuerung hat sowohl für Inhaltsersteller als auch für Verbraucher erhebliche Vorteile und verringert das Risiko von Unterbrechungen aufgrund von Dateiverlusten oder der Unfähigkeit, Änderungen zurückzugeben.

Der erste Schritt zum Einrichten der Versionssteuerung besteht darin, zu entscheiden, wie Sie Inhalte entwickeln.

Entscheiden, wie Inhalte entwickelt werden sollen

Je nachdem, wie Sie Inhalte erstellen, treffen Sie unterschiedliche Entscheidungen zur Verwaltung. Für Power BI-Berichte und semantische Modelle verfügt beispielsweise eine Power BI Desktop-Datei (PBIX) über weniger Optionen für die Versionssteuerung im Vergleich zum Power BI Desktop-Projektformat (PBIP). Das liegt daran, dass eine PBIX-Datei ein Binärformat ist, während das PBIP-Format textbasierte, lesbare Inhalte und Metadaten enthält. Die Verwendung von lesbaren Inhalten und Metadaten ermöglicht die einfachere Nachverfolgung von Modell- und Berichtsänderungen mithilfe der Quellcodeverwaltung. Die Quellcodeverwaltung ist das Anzeigen und Verwalten von Änderungen innerhalb von Inhalten in seinem Code und seinen Metadaten.

Tipp

Beim Entwickeln von semantischen Modellen und Berichten mithilfe von Power BI Desktop wird empfohlen, PBIP-Dateien anstelle von PBIX-Dateien zu verwenden. Bei der Entwicklung von semantischen Modellen mithilfe von XMLA-Tools empfehlen wir, anstelle von BIM-Dateien das TMDL-Format (Tabular Model Definition Language) zu verwenden. Weitere Informationen finden Sie unter "Entscheiden des Formats Ihrer Inhalte weiter unten in diesem Artikel".

Power BI Desktop

Sie können Power BI Desktop verwenden, um semantische Modelle oder Berichte zu erstellen, die Sie als PBIX- oder PBIP-Dateien speichern können. Es gibt zusätzliche benutzerdefinierte Inhaltsdateien, die Sie auch verwenden können, wenn Sie Power BI Desktop verwenden. Wenn Sie Power BI Desktop zum Erstellen von Inhalten verwenden, sollten Sie einige wichtige Entscheidungen treffen:

• Welches Dateiformat verwendet werden soll: Sie können Inhalte entweder als PBIX- oder PBIP-Dateien speichern. Weitere Informationen finden Sie unter "Entscheiden des Formats Ihrer Inhalte weiter unten in diesem Artikel".
• Verwalten von benutzerdefinierten Inhalten: Sie können Designs, benutzerdefinierte visuelle Elemente oder Bilder zu Power BI Desktop-Dateien hinzufügen, die möglicherweise unterschiedliche Überlegungen zur Lebenszyklusverwaltung erfordern. Wenn Inhaltsersteller beispielsweise eigene benutzerdefinierte visuelle Elemente erstellen, sollten sie die visuelle Definition in einer separaten Datei speichern und verwalten.
• Verwalten von Vorschaufeatures: Sie können sich für Vorschaufeatures oder -einstellungen in Power BI Desktop entscheiden, die den Inhalt und dessen Verwendung verändern. Beispielsweise können Sie zusätzliche Schritte ausführen, um Inhalte zu überprüfen, die Vorschaufeatures verwenden.

Weberstellung

Bestimmte Inhalte wie Datenflüsse, Dashboards und Scorecards können nur im Fabric-Portal erstellt werden. Sie können auch inhalte , z. B. semantische Modelle, Berichte und paginierte Berichte, sowohl im Fabric-Portal als auch mithilfe lokaler Tools erstellen oder ändern. Beim Erstellen von Inhalten mithilfe der Weberstellung sollten Sie einige wichtige Entscheidungen treffen:

• Verwalten von Änderungen: Sie können Änderungen an vielen Elementtypen vornehmen, indem Sie die Weberstellung verwenden, aber diese Änderungen werden möglicherweise sofort gespeichert und frühere Versionen überschreiben. Wenn Sie beispielsweise mit anderen zusammenarbeiten, sollten Sie die Weberstellung für freigegebene Elemente vermeiden und stattdessen an Ihrer eigenen Kopie arbeiten.
• So rufen Sie Inhaltssicherungen ab: Sie können Inhalte wie Berichte oder semantische Modelle mithilfe der Weberstellung erstellen, diese Elemente können jedoch nicht in lokale PBIX-Dateien heruntergeladen werden. Beispielsweise können Sie diese Inhalte sichern, indem Sie dessen Metadaten abrufen und speichern.

Tipp

Beim Entwickeln von Datenflüssen und Scorecards sollten Sie die Elementdefinitionen abrufen, um Änderungen zu verwalten und eine Sicherung zu speichern. Sie können den Datenfluss und den Scorecardabruf mithilfe der Fabric-REST-APIs automatisieren. Insbesondere können Sie die Endpunkte "Get Dataflow " bzw. " Get Scorecards " verwenden.

Vorsicht

Einige Inhalte , z. B. Dashboards, haben nicht die Möglichkeit, eine Definition abzurufen. Für diese Inhalte können Sie keine Änderungen einfach nachverfolgen oder eine Sicherung abrufen.

Weitere Tools

Sie können andere Tools zum Erstellen oder Verwalten bestimmter Inhaltstypen verwenden. Diese Tools bieten möglicherweise zusätzliche Vorteile, passen besser zu Ihrem Workflow oder werden benötigt, um bestimmte Funktionen oder Inhaltstypen zu verwalten. Sie können sowohl andere Microsoft-Tools als auch Tools von Drittanbietern verwenden, um Inhalte zu erstellen und zu verwalten. Andere Tools, die Sie zum Erstellen oder Verwalten von Inhalten verwenden können, sind wie folgt.

• Visual Studio oder Visual Studio Code: Eine integrierte Entwicklungsumgebung, in der Entwickler semantische Modelle oder Fabric-Notizbücher erstellen und verwalten können. Mit Visual Studio und Visual Studio Code können Entwickler auch die Quellcodeverwaltung (Source Control Management, SCM) ausführen, indem lokale Änderungen an ein Remote-Repository übertragen werden.
• Tabellarischer Editor: Ein Drittanbietertool zum Entwickeln und Verwalten von semantischen Modellen.
• Excel: Ein Clienttool für PivotTables und live verbundene Tabellen, die mit einem semantischen Modell arbeiten.
• Power BI-Berichts-Generator: Eine Desktopanwendung zum Erstellen von Paginierten Berichtsdateien (RDL).

Beim Erstellen von Inhalten mithilfe anderer Tools sollten Sie einige wichtige Entscheidungen treffen:

• Verwalten von Lizenzen: Andere Tools erfordern möglicherweise zusätzliche Lizenzen, die Sie verwalten sollten.
• Veröffentlichen von Inhalten: Andere Tools erfordern möglicherweise zusätzliche Schritte zum Veröffentlichen von Inhalten, z. B. mithilfe von XMLA-Endpunkten oder power BI-REST-APIs.

Nachdem Sie sich entschieden haben, wie Sie Inhalte erstellen, müssen Sie als Nächstes auswählen, welches Format Sie zum Speichern und Verwalten verwenden.

Festlegen des Formats Ihrer Inhalte

Je nachdem, welche Inhalte Sie erstellen und welche Tools Sie verwenden, verwenden Ihre Inhalte möglicherweise unterschiedliche Dateiformate. Selbst innerhalb eines Tools müssen Sie jedoch zwischen verschiedenen Formaten wählen. Beispielsweise müssen Sie für Berichte und semantische Modelle, die Sie mit Power BI Desktop erstellen, zwischen PBIX- und PBIP-Dateien wählen. Diese Entscheidung wirkt sich nicht nur darauf aus, wie Sie Inhalte entwickeln, sondern auch, wie Sie diese Inhalte während des Lebenszyklus verwalten und wie effizient Sie bestimmte Entwicklungsaufgaben ausführen können. Beispielsweise müssen Sie PBIP-Dateien verwenden, wenn Sie Inhalte in Power BI Desktop entwickeln möchten, aber diese Inhalte mithilfe der Git-Integration veröffentlichen möchten.

Das Dateiformat für Ihre Inhalte kann sich während des Lebenszyklus ändern. Beispielsweise können Sie mit der Erstellung von PBIX-Dateien für Berichte und Modelle zunächst beginnen. Wenn neue Inhaltsersteller jedoch mit Ihnen zusammenarbeiten möchten oder Wenn Sie Ihre Produktivität verbessern möchten, können Sie zu einem anderen Format wechseln, z. B. PBIP-Dateien.

In den folgenden Abschnitten finden Sie eine Übersicht über gängige Formate, die Sie in Power BI auswählen müssen.

Power BI Desktop (PBIX)-Dateiformat

Das Standardformat und das am häufigsten verwendete Format für Power BI-Berichte und -Modelle ist das PBIX-Dateiformat. Dieses Binärformat ist für die meisten Benutzer einfach zu verwalten und zu verwenden. Es ist jedoch nicht möglich, die Dateiinhalte zu öffnen oder zu verwenden, um Änderungen nachzuverfolgen oder die Produktivität der Entwickler zu verbessern.

Verwenden Sie das PBIX-Dateiformat, wenn:

• Sie planen, Inhalte mithilfe der OneDrive-Aktualisierung zu veröffentlichen.
• Inhaltsersteller möchten eine einzelne Datei anstelle eines Ordners mehrerer Dateien (z. B. im PBIP-Format) verwenden und freigeben.
• Inhaltsersteller bevorzugen das PBIX-Format, da sie es einfacher finden.

Power BI Projects (PBIP)-Dateiformat

Statt einer PBIX-Datei können Sie Inhalte auch im Power BI Projects (PBIP) -Format speichern. Dieses Format teilt die Datei in eine Ordnerstruktur auf. In der Ordnerstruktur einer PBIP gibt es mehrere Metadatendateien, die Sie öffnen und lesen können, die die Definitionen und Konfigurationen für Modelle und Berichte bereitstellen. Da Sie den Dateiinhalt öffnen und lesen können, können Sie Änderungen an ihnen manuell oder programmgesteuert vornehmen, was zu erheblichen Produktivitätsverbesserungen führen kann. Bestimmte Features in Fabric wie z. B. die Git-Integration erfordern auch, dass Sie das PBIP-Format anstelle des PBIX-Formats verwenden, wenn Sie Inhalte in Power BI Desktop entwickeln.

Die folgende Abbildung zeigt, wie PBIX-Dateien und PBIP-Dateien unterschiedlich sind:

Zusammenfassend können Benutzer oder automatisierte Prozesse den Inhalt einer PBIP-Datei anzeigen und ändern, ohne sie in Power BI Desktop zu öffnen. Im Gegensatz dazu ist eine PBIX-Datei eine Binärdatei, und es gibt keine unterstützten Methoden zum Anzeigen oder Ändern des Inhalts. Es gibt verschiedene Szenarien, in denen Sie diese Metadateninhalte anzeigen oder ändern möchten, z. B.:

• Sie möchten die Versionskontrolle durchführen, indem Sie Änderungen nachverfolgen und verwalten, und dabei den Überblick behalten, was sich geändert hat.
• Sie möchten Massenänderungen vornehmen oder nach etwas in der Datei suchen.
• Sie möchten Elemente der Datei wiederverwenden, z. B. ein visuelles Element, eine Tabelle oder ein Measure.
• Sie möchten Eigenschaften oder Einstellungen anzeigen, die auf der Benutzeroberfläche von Power BI Desktop nicht sichtbar sind.
• Sie möchten bestimmte Prozesse automatisieren, z. B. das Scannen von Metadaten auf Verstöße gegen bewährte Methoden vor dem Veröffentlichen von Inhalten.

Das PBIP-Dateiformat kann auch die TMDL - oder PBIR-Formate für semantische Modell- bzw. Berichtsdefinitionen verwenden, die ihre eigenen Vorteile und Überlegungen haben, die sie berücksichtigen sollten.

Verwenden Sie das PBIP-Dateiformat, wenn:

• Sie planen die Git-Integration und nicht die OneDrive-Aktualisierung zum Veröffentlichen oder Bereitstellen von Inhalten.
• Sie planen die Verwendung der Quellcodeverwaltung zum Nachverfolgen und Verwalten von Änderungen.
• Sie planen die Verwendung von Power BI Desktop in Kombination mit anderen Tools zum Entwickeln von Modellen oder Berichten.
• Mehrere Inhaltsproduzenten arbeiten gemeinsam an Modellen oder Berichten.
• Sie möchten von Produktivitätsverbesserungen profitieren und Zeit sparen, um Modelle oder Berichte zu erstellen.
• Sie planen, Teile des Entwicklungs-, Test- oder Bereitstellungsprozesses zu automatisieren.
• Sie möchten Ihr Modell und Berichtsdateien auf unterschiedliche Weise strukturieren (z. B. mehrere Berichte in der . Berichtsordner und mehrere Modelle in der . SemanticModel-Ordner).

Tipp

Wenn Sie Inhalte entwickeln, sollten Sie szenarien, in denen Sie das Gefühl haben, Zeit zu verschwenden, z. B. mit wiederholten Aufgaben, selbst bewusst sein. In diesen Szenarien können Sie oft Zeit sparen, indem Sie diese neuen Formate zusammen mit anderen Tools wie Visual Studio Code, Notizbüchern in Fabric und mehr nutzen.

Dateiformat für tabellarische Modelldefinitionssprache (TMDL)

Wenn Sie ein Modell als .pbip speichern, können Sie es entweder als einzelne .bim-Datei, die die Skriptsprache der Tabellarischen Modellierung (Tabular Model Scripting Language, TMSL) nutzt, oder in einer Ordnerstruktur mit mehreren .tmdl-Dateien speichern, die die neue Tabellarische Modelldefinitionssprache verwenden. TMDL verwendet eine YAML-ähnliche Syntax für semantische Modelldefinitionen, die das Lesen und Verwalten von Änderungen eines Modells vereinfachen.

Im Folgenden sehen Sie ein Beispiel dafür, wie das TMDL-Format aussieht:

Einige Vorteile des neuen TMDL-Formats sind wie folgt:

• Sie können die Quellcodeverwaltung und git-Integration besser verwenden, da Modellmetadaten präziser, strukturierter und einfacher zu lesen sind.
• Sie können Änderungen einfacher zusammenführen, ohne Konflikte zu erstellen.
• Sie können Ihre Effizienz für bestimmte Berichterstellungsaufgaben verbessern, z. B. das Erneute Verwenden oder Kopieren von Modellobjekten zwischen Modellen (z. B. eine Datumstabelle).

Im Folgenden sehen Sie ein Beispiel dafür, wie die Quellcodeverwaltung mit dem TMDL-Format aussieht:

Verwenden Sie das TMDL-Format, wenn:

• Sie planen die Verwendung der Quellcodeverwaltung zum Nachverfolgen und Verwalten von Änderungen.
• Sie möchten die Produktivität der Entwickler verbessern, indem Sie Metadatenänderungen vornehmen.
• Sie entwickeln Ihr semantisches Modell mit anderen Tools, z. B. Visual Studio Code oder Tabellarischer Editor.

Hinweis

Das TMDL-Format unterscheidet sich von der TMDL-Ansicht in Power BI Desktop:

• TMDL ist ein Sprach- und Metadatenformat für semantische Modelle.
• Die TMDL-Ansicht ist eine Skriptschnittstelle in Power BI Desktop, über die Sie programmgesteuerte Änderungen am Modell vornehmen können. Es verwendet eine ähnliche YAML-ähnliche Syntax für TMDL-Skripts als TMDL-Formatdateien. Sie müssen das TMDL-Format nicht verwenden, um von der TMDL-Ansicht zu profitieren.

Power BI Enhanced Report (PBIR)-Format.

Wenn Sie Inhalte als PBIP-Datei speichern, können Sie das Standardberichtsformat oder das neue PBIR-Format verwenden. Dieses neue Format bietet mehrere Vorteile, die die Produktivität und Zusammenarbeit von Entwicklern verbessern können, insbesondere wenn Sie das PBIR-Format mit PBIP-Dateien verwenden.

Im Folgenden sehen Sie ein Beispiel dafür, wie das PBIR-Format aussieht:

Einige Vorteile der Verwendung des PBIR-Formats sind wie folgt:

• Sie können die Quellcodeverwaltung und git-Integration besser verwenden, da Berichtsmetadaten präziser, strukturierter und einfacher zu lesen sind.
• Sie können Ihre Effizienz für bestimmte Berichtsaufgaben verbessern, z. B.:
  • Das erneute Verwenden oder Kopieren von visuellen Elementen zwischen Seiten durch Kopieren der visual.json.
  • Erneutes Verwenden oder Kopieren von Seiten zwischen Berichten
  • Suchen und Ersetzen von benutzerdefinierten Farben, Feldern und anderen visuellen Konfigurationen auf einmal.
  • Korrigieren von "fehlerhaften" visuellen Elementen mit Feldern, die umbenannt oder zwischen Tabellen verschoben wurden.
• Sie können Metadatenanmerkungen hinzufügen, um Metadaten zu melden, um bestimmte Automatisierungen oder Aufgaben zu vereinfachen, die eine kontinuierliche Integration / kontinuierliche Bereitstellung (CI/CD) unterstützen.
• Sie können Tools wie semantische Linklabore nutzen, die mit dem neuen PBIR-Format mehr Nutzen haben.

Verwenden Sie das PBIR-Format, wenn:

• Sie planen die Verwendung der Quellcodeverwaltung zum Nachverfolgen und Verwalten von Änderungen.
• Sie möchten die Produktivität des Berichtserstellers verbessern, indem Sie Metadatenänderungen vornehmen.
• Sie möchten programmgesteuerte oder automatische Änderungen am Bericht vornehmen.

Vorsicht

Stellen Sie sicher, dass Sie zuerst die Einschränkungen und Überlegungen überprüfen, bevor Sie das PBIR-Format verwenden. Diese Einschränkungen und Überlegungen ändern sich im Laufe der Zeit. Überprüfen Sie daher regelmäßig, ob bestimmte Elemente vorhanden sind, die verhindern, dass Sie eine bestimmte Anforderung für Ihre Power BI-Inhalte erfüllen.

Darüber hinaus haben alle Berichtsmetadaten unabhängig vom Format das Potenzial, Datenpunkte einzuschließen. Weitere Informationen finden Sie unter PBIR-Ordner und -Dateien.

Power BI-Vorlagendateiformat (.pbit)

Sie können einen Power BI-Bericht oder ein semantisches Modell auch als PBIT-Datei speichern. PBIT-Dateien sind jedoch für die erneute Verwendung eines bestimmten Berichtslayouts oder einer Modellstruktur vorgesehen. Sie sollten das PBIT-Format nicht zum Speichern und Verwalten von Power BI-Inhalten während der Entwicklung verwenden. Stattdessen sollten Sie PBIT-Dateien verwenden, wenn Sie wiederverwendbare Vorlagen erstellen möchten, um sie für andere Personen in Ihrer Organisation freizugeben.

Andere Formate

Wenn Sie andere Inhalte in Power BI entwickeln (z. B. Dashboards, Datenflüsse oder paginierte Berichte), verfügen Sie möglicherweise nicht über Inhaltsdateien, wenn Sie das Element in Fabric entwickeln. Alternativ können Sie die Definition des Elements nur in der Quellcodeverwaltung speichern lassen. Weitere Informationen finden Sie unter "Entscheiden, wo Dateien im vorherigen Artikel dieser Reihe gespeichert werden sollen.

Entscheiden, wie Sie Arbeitsbereiche einrichten und verwenden

Beim Entwickeln von Inhalten sollten Sie mehrere Arbeitsbereiche (oder Phasen) verwenden, um Produktionsinhalte zu trennen, die von der Organisation verwendet werden, von inhalten, die entwickelt oder überprüft werden. Es gibt mehrere Vorteile bei der Verwendung separater Arbeitsbereiche für Ihre Inhalte:

• Sie können Inhalte entwickeln und testen, ohne dass sich dies auf die aktuell verwendeten Inhalte auswirkt. Dadurch werden Änderungen vermieden, die zu unbeabsichtigten Unterbrechungen von Inhalten in der Produktion führen können.
• Sie können separate Ressourcen zum Entwickeln und Testen von Inhalten verwenden, z. B. durch separate Datengateways oder Fabric-Kapazitäten. Dadurch wird vermieden, dass Ressourcen, die für die Entwicklung und Tests verwendet werden, Produktionsworkloads stören, wodurch langsame Datenaktualisierungen oder Berichte verursacht werden.
• Sie können einen strukturierteren Prozess erstellen, um Inhalte zu entwickeln, zu testen und freizugeben, indem Sie für jede dieser Phasen separate Umgebungen verwenden. Dies hilft Ihnen, die Produktivität zu verbessern.

In Fabric und Power BI wird empfohlen, separate Fabric-Arbeitsbereiche zu verwenden, wie in den Planungsartikeln auf Mandantenebene und Arbeitsbereichsebene beschrieben.

Von Bedeutung

Die Verwendung separater Umgebungen ist ein wesentlicher Schritt, um den Erfolg Ihres Content-Lifecycle-Management-Ansatzes sicherzustellen.

Es gibt mehrere Möglichkeiten, Fabric-Arbeitsbereiche zum Trennen von Umgebungen zu verwenden. In der Regel verwenden Sie neben Ihrer lokalen Umgebung zwei oder mehr Arbeitsbereiche, um Inhalte während des Lebenszyklus zu verwalten.

Beantworten Sie die folgenden Fragen, während Sie planen, wie Sie separate Arbeitsbereiche während des gesamten Lebenszyklus dieser Inhalte verwenden:

• Wie viele Arbeitsbereiche benötigen Sie?
• Werden Sie Arbeitsbereiche nach Elementtyp trennen?
• Wer hat Zugriff auf jeden Arbeitsbereich?
• Gehören die Arbeitsbereiche zu einer Fabric-Bereitstellungspipeline oder koordinieren Sie die Bereitstellung mithilfe anderer Ansätze, z. B. mithilfe von Azure-Pipelines?
• Wie verwalten Sie die arbeitsbereichübergreifende Veröffentlichung? Müssen Sie beispielsweise sicherstellen, dass Berichte in einem Testarbeitsbereich für Berichte eine Verbindung mit semantischen Modellen in einem separaten Testarbeitsbereich für Datenelemente herstellen?
• Benötigen Sie auch separate unterstützende Ressourcen für Elemente in Produktionsumgebungen, wie zum Beispiel einen separaten lokalen Datengateway-Cluster?

In den folgenden Abschnitten finden Sie eine allgemeine Übersicht über die verschiedenen Ansätze, die Sie zum Trennen von Arbeitsbereichen ergreifen können, um die Lebenszyklusverwaltung zu erleichtern.

Hinweis

In den folgenden Abschnitten wird erläutert, wie Sie separate Arbeitsbereiche einrichten und verwenden können. Sie können Inhalte in diesen Arbeitsbereichen bereitstellen, indem Sie einen der folgenden vier Ansätze verwenden:

• Veröffentlichung aus Power BI Desktop.
• Bereitstellung von Inhalten aus einem anderen Arbeitsbereich durch die Verwendung von Fabric-Bereitstellungspipelines.
• Synchronisieren von Inhalten aus einem Remote-Git-Repository mithilfe der Git-Integration.
• Programmgesteuerte Bereitstellung von Inhalten mithilfe der Fabric-REST-APIs, Power BI-REST-APIs oder XMLA-Endpunkte.

Weitere Informationen zu diesen Ansätzen für die Bereitstellung von Inhalten finden Sie in Phase 4: Bereitstellen von Inhalten weiter unten in dieser Reihe.

Test- und Produktionsarbeitsbereiche

Wenn Sie einfachere Inhalte bereitstellen, die für die Organisation nicht wichtig sind, können zwei Arbeitsbereiche häufig ausreichen. In diesem Szenario verfügen Inhaltsersteller in der Regel über eingeschränkte Zusammenarbeit auf denselben Elementen und entwickeln Inhalte lokal.

Das folgende Diagramm zeigt ein allgemeines Beispiel, wie Sie separate Umgebungen nutzen können, indem Sie nur einen Test- und einen Produktionsarbeitsbereich verwenden.

Das Diagramm zeigt die folgenden Prozesse und Komponenten zum Trennen von Arbeitsbereichen in diesem Ansatz.

Element	Beschreibung
	Inhaltsersteller entwickeln Inhalte in ihrer lokalen Umgebung.
	Wenn sie bereit sind, veröffentlichen Inhaltsersteller Inhalte in einem Testarbeitsbereich. Inhaltsersteller können Inhalte entwickeln, die nur durch Web-Autorentools erstellt werden können, und eine Inhaltsüberprüfung in der Testumgebung durchführen.
	Wenn sie bereit sind, stellen Inhaltsersteller Inhalte in einem Produktionsarbeitsbereich bereit. Im Produktionsarbeitsbereich verteilen Inhaltsersteller Inhalte, indem sie eine Power BI-App veröffentlichen oder Inhalte aus dem Arbeitsbereich freigeben.

Hinweis

Es gibt viele verschiedene Möglichkeiten, separate Arbeitsbereiche einzurichten und zu verwenden und Inhalte zwischen diesen Arbeitsbereichen bereitzustellen. Es wird jedoch empfohlen, keine lokale Entwicklung durchzuführen, und dann Inhalte direkt in einem Produktionsarbeitsbereich zu veröffentlichen. Dies kann zu verhinderbaren Störungen und Fehlern führen.

Entwicklungs-, Test- und Produktionsarbeitsbereiche

Bei der Bereitstellung unternehmenskritischer Inhalte verwenden Sie in der Regel drei oder mehr separate Arbeitsbereiche. In diesem Szenario arbeiten Inhaltsersteller häufig in einem zusätzlichen Entwicklungsarbeitsbereich zusammen, der die neueste Version der Lösung enthält.

Das folgende Diagramm zeigt ein allgemeines Beispiel dafür, wie Sie separate Umgebungen mit einem Entwicklungs-, Test- und Produktionsarbeitsbereich verwenden können.

Das Diagramm zeigt die folgenden Prozesse und Komponenten zum Trennen von Arbeitsbereichen in diesem Ansatz.

Element	Beschreibung
	Inhaltsersteller entwickeln Inhalte in ihrer lokalen Umgebung.
	Wenn sie bereit sind, veröffentlichen Inhaltsersteller Inhalte in einem Entwicklungsarbeitsbereich. Im Entwicklungsarbeitsbereich können Inhaltsersteller Inhalte entwickeln, die nur mit der Weberstellung erstellt werden können. Inhaltsersteller können auch Inhalte im Entwicklungsarbeitsbereich überprüfen.
	Wenn sie bereit sind, stellen Inhaltsersteller Inhalte in einem Testarbeitsbereich bereit. Im Testarbeitsbereich überprüfen Benutzer Inhalte entweder im Arbeitsbereich oder in einer App.
	Wenn sie bereit sind, stellen Inhaltsersteller Inhalte in einem Produktionsarbeitsbereich bereit. Im Produktionsarbeitsbereich verteilen Inhaltsersteller Inhalte, indem sie eine Power BI-App veröffentlichen oder Inhalte aus dem Arbeitsbereich freigeben.

Hinweis

Sie können bis zu zehn verschiedene Umgebungen mit Bereitstellungspipelines verwenden. Sie können z. B. eine Vorproduktionsumgebung zwischen Test und Produktion haben, die speziell für spezielle Überprüfungsarten wie Leistungstests vorgesehen ist.

Privater Arbeitsbereich mit Git-Integration

Bei der Bereitstellung unternehmenskritischer Inhalte kann jeder Entwickler auch einen eigenen , privaten Arbeitsbereich für die Entwicklung verwenden. In diesem Szenario ermöglicht ein privater Arbeitsbereich Inhaltserstellern, Inhalte im Fabric-Portal zu testen oder Funktionen wie geplante Aktualisierungen zu nutzen, ohne das Risiko einzugehen, das Entwicklungsteam zu stören. Inhaltsersteller können hier auch Inhalte im Fabric-Portal entwickeln, z. B. Datenflüsse. Private Arbeitsbereiche können eine gute Wahl sein, wenn Sie Inhaltsänderungen mithilfe der Git-Integration zusammen mit Azure DevOps verwalten.

Hinweis

Azure DevOps ist eine Suite von Diensten, die in Power BI und Fabric integriert werden, um Sie bei der Planung und Orchestrierung der Inhaltslebenszyklusverwaltung zu unterstützen. Wenn Sie Azure DevOps auf diese Weise verwenden, nutzen Sie in der Regel die folgenden Dienste:

• Azure Repos: Ermöglicht Ihnen das Erstellen und Verwenden eines Remote-Git-Repositorys, bei dem es sich um einen Remotespeicherort handelt, den Sie zum Nachverfolgen und Verwalten von Inhaltsänderungen verwenden.
• Azure Pipelines: Ermöglicht Ihnen das Erstellen und Verwenden einer Reihe automatisierter Aufgaben zum Verarbeiten, Testen und Bereitstellen von Inhalten aus einem Remote-Repository in einem Arbeitsbereich.
• Azure Test Plans: Ermöglicht Ihnen das Entwerfen von Tests, um die Lösung zu überprüfen und die Qualitätskontrolle zusammen mit Azure-Pipelines zu automatisieren.
• Azure Boards: Ermöglicht Es Ihnen, Boards zum Nachverfolgen von Aufgaben und Plänen als Arbeitsaufgaben zu verwenden und Arbeitsaufgaben aus anderen Azure DevOps-Diensten zu verknüpfen oder darauf zu verweisen.
• Azure Wiki: Ermöglicht Ihnen, Informationen mit ihrem Team zu teilen, um Inhalte zu verstehen und zu ihnen beizutragen.

Das folgende Diagramm zeigt ein allgemeines Beispiel für die Verwendung separater Umgebungen mithilfe eines privaten Arbeitsbereichs mit Git-Integration.

Hinweis

Das Diagramm zeigt separate Entwickler, die an separaten Verzweigungen einer Lösung (Verzweigung 1 und Verzweigung 2) arbeiten, bevor sie ihre Änderungen in einer Hauptzweigung zusammenführen. Dies ist eine vereinfachte Darstellung einer Git Branching-Strategie , um zu veranschaulichen, wie Entwickler ihre Änderungen in ein Remote-Git-Repository integrieren und von der Git-Integration in Fabric profitieren können.

Das Diagramm zeigt die folgenden Prozesse und Komponenten zum Trennen von Arbeitsbereichen in diesem Ansatz.

Element	Beschreibung
	Jeder Inhaltsersteller entwickelt Inhalte in ihrer eigenen lokalen Umgebung.
	Wenn sie bereit sind, übernehmen Inhaltsersteller ihre Änderungen an ein Remote-Repository, z. B. ein Azure Repos Git-Repository, und übertragen sie.
	Im Remote-Git-Repository können Inhaltsersteller Inhaltsänderungen mithilfe der Quellcodeverwaltung nachverfolgen und verwalten sowie Inhalte verzweigen und zusammenführen, um die Zusammenarbeit zu erleichtern.
	Inhaltsersteller synchronisieren einen Zweig des Remote-Repositorys mit einem privaten Arbeitsbereich. Nach der Synchronisierung werden die neuesten Änderungen, die ein Ersteller an die Verzweigung überträgt, in diesem privaten Arbeitsbereich angezeigt. Verschiedene Inhaltsautoren arbeiten an ihren eigenen, separaten Zweigen, während sie Änderungen vornehmen.
	In den privaten Arbeitsbereichen können Inhaltsersteller Inhalte mithilfe der Weberstellung entwickeln und ihre eigenen Änderungen überprüfen. Änderungen an Inhalten, die durch Web-Autoren vorgenommen werden, können mit der Verzweigung im Git-Repository synchronisiert werden, wenn der Inhaltsersteller diese Änderungen im Arbeitsbereich commitet und pusht. Verschiedene Inhaltsersteller arbeiten in eigenen, separaten privaten Arbeitsbereichen.
	Wenn sie bereit sind, führen Inhaltsersteller eine Pullanforderung aus, um ihre Änderungen in den Hauptzweig der Lösung zusammenzuführen.
	Nach dem Zusammenführen von Änderungen synchronisiert sich der Hauptzweig mit dem Entwicklungsarbeitsbereich.
	Im Entwicklungsarbeitsbereich können Inhaltsersteller Inhalte entwickeln, die von der Fabric Git-Integration nicht unterstützt werden, z. B. Dashboards. Inhaltsersteller überprüfen auch die integrierte Lösung, die alle neuesten Änderungen enthält.
	Wenn sie bereit sind, stellen Inhaltsersteller Inhalte in einem Testarbeitsbereich bereit. Im Testarbeitsbereich führen Benutzer Benutzerakzeptanztests von Inhalten durch.
	Wenn sie bereit sind, stellen Inhaltsersteller Inhalte in einem Produktionsarbeitsbereich bereit. Im Produktionsarbeitsbereich verteilen Inhaltsersteller Inhalte, indem sie eine Power BI-App veröffentlichen oder Inhalte aus dem Arbeitsbereich freigeben.

Unterstützende Ressourcen für Arbeitsbereiche

Wenn Sie separate Umgebungen verwenden, sollten Sie auch berücksichtigen, wie sich dies auf verschiedene unterstützende Ressourcen auswirkt, die Sie in diesen Umgebungen verwenden. Berücksichtigen Sie bei diesen Unterstützenden Ressourcen, ob Sie sie auch in dieselbe Anzahl von Phasen aufteilen müssen oder wie Sie die Verwendung in diesen Umgebungen koordinieren.

• Gateways: Erwägen Sie die Verwendung separater lokaler Datengatewaycluster und VNet-Gateways für Produktionsworkloads. Dies ist von Vorteil, um Unterbrechungen zu verhindern, aber auch, um die Betriebszeit sicherzustellen, wenn Sie diese Gateways aktualisieren müssen.
• Apps: Erwägen Sie separate Apps für Test- und Produktionsarbeitsbereiche. Es ist nicht möglich, Apps zwischen Phasen bereitzustellen oder zu kopieren. Apps im Testarbeitsbereich sollen Ihnen dabei helfen, Inhalte und die App-Erfahrung zu testen, bevor Sie Änderungen am Produktionsarbeitsbereich bereitstellen. Apps im Produktionsarbeitsbereich sollen Inhalte für Endbenutzer in einer strukturierten Umgebung bereitstellen.
• Azure DevOps: Wenn Sie Azure DevOps für die Zusammenarbeit und die Orchestrierung der Quellcodeverwaltung und -bereitstellung verwenden möchten, überlegen Sie, wie Sie Branches und Azure-Pipelines verwenden, um Inhalte zwischen diesen Umgebungen bereitzustellen. Weitere Informationen zur Verwendung von Azure Pipelines zum Bereitstellen von Inhalten finden Sie in Phase 4: Bereitstellen von Inhalten.

Nachdem Sie entschieden haben, wie Sie Arbeitsbereiche einrichten und verwenden, besteht der nächste Schritt darin, zu entscheiden, wie Sie die Versionssteuerung ausführen, um Inhaltsänderungen nachzuverfolgen und zu verwalten.

Entscheiden, wie Sie die Versionssteuerung verwenden

In Power BI können Sie die Versionsverwaltung entweder mithilfe von SharePoint/OneDrive oder mithilfe eines Remote-Git-Repositorys wie Azure Repos ausführen, das eine Komponente von Azure DevOps ist. Anstelle von Azure DevOps können Sie auch GitHub verwenden. In beiden Ansätzen fügen Sie lokale Inhaltsdateien zu einem Remotespeicherort hinzu, um Änderungen nachzuverfolgen und zu verwalten. Es wird empfohlen, SharePoint oder OneDrive nur für kleinere und einfachere Projekte zu verwenden, da es an Features und Robustität fehlt, um größere oder kompliziertere Szenarien zu unterstützen.

Im Folgenden finden Sie einige allgemeine Überlegungen, die Sie beim Einrichten und Verwenden der Versionssteuerung unterstützen.

• Warnungen: Sie sollten Warnungen einrichten, wenn andere wichtige Dateien hinzufügen, entfernen oder ändern.
• Bereich: Definieren Sie eindeutig den Bereich des Remotespeicherorts. Im Idealfall ist der Bereich des Remotespeicherorts identisch mit dem Umfang der nachgeschalteten Arbeitsbereiche und Apps, die Sie zum Bereitstellen von Inhalten für Verbraucher verwenden.
• Access: Sie sollten den Zugriff auf den Remotespeicherort mithilfe eines ähnlichen Berechtigungsmodells einrichten, wie Sie für Ihre Bereitstellungspipelineberechtigungen und Arbeitsbereichsrollen eingerichtet haben. Inhaltsersteller benötigen Zugriff auf den Remotespeicherort.
• Dokumentation: Fügen Sie dem Remotespeicherort Textdateien hinzu, um den Remotespeicherort und dessen Zweck, Besitz, Zugriff und definierte Prozesse zu beschreiben.

In den folgenden Abschnitten werden die einzelnen Ansätze und wichtigsten Überlegungen beschrieben, um zu entscheiden, welches Sie verwenden sollten.

Versionssteuerung mithilfe von SharePoint oder OneDrive for Work and School

SharePoint verfügt über integrierte Versionssteuerung für Dateien. Inhaltsersteller können semantische Modelle oder Berichte lokal entwickeln und ihre Änderungen werden mit einer SharePoint- oder OneDrive for Work and School-Dokumentbibliothek synchronisiert.

Tipp

Verwenden Sie SharePoint oder OneDrive nur für die Versionssteuerung in einfacheren, kleineren Szenarien, z. B. Self-Service Content Publishing. Bei größeren oder komplizierteren Szenarien sollten Sie die Quellcodeverwaltung mithilfe eines Git-Remoterepositorys durchführen.

Das folgende Diagramm zeigt eine allgemeine Übersicht über die Ausführung der Versionssteuerung mithilfe von SharePoint oder OneDrive.

Das Diagramm beschreibt die folgenden Prozesse und Komponenten.

Element	Beschreibung
	Inhaltsersteller entwickeln semantische Modelle und Berichte in ihrer lokalen Umgebung und speichern diese Modelle und Berichte als PBIX-Dateien.
	Wenn sie bereit sind, speichern Inhaltsersteller ihre Änderungen, die sie mit einer SharePoint- oder OneDrive for Work and School-Bibliothek synchronisieren.
	In der Remotebibliothek verfolgen Inhaltsersteller Änderungen auf Dateiebene, wodurch die Versionssteuerung erleichtert wird.
	Inhaltsersteller können ein veröffentlichtes Semantikmodell oder einen Bericht mit einer PBIX-Datei verknüpfen, um die OneDrive-Aktualisierung zu erleichtern. Bei der OneDrive-Aktualisierung werden Inhaltsänderungen automatisch jede Stunde veröffentlicht.
	Im Fabric-Arbeitsbereich sehen Inhaltsersteller die Änderungen an Power BI-Inhalten nach Abschluss der OneDrive-Aktualisierung.

Von Bedeutung

Sie können die Versionssteuerung nur mithilfe von SharePoint- oder OneDrive für Power BI-Desktopdateien ausführen, die semantische Modelle oder Berichte enthalten. Sie können die Versionsverwaltung nicht einfach mithilfe von SharePoint oder OneDrive für andere Power BI-Elementtypen wie Datenflüsse oder für Fabric-Elementtypen wie Notizbücher ausführen. Für diese anderen Elementtypen sollten Sie die Versionsverwaltung mithilfe eines Remote-Git-Repositorys wie Azure Repos ausführen.

Inhaltsersteller können ein veröffentlichtes Semantikmodell oder einen Bericht mit einer PBIX-Datei verknüpfen , die in einer SharePoint- oder OneDrive for Work and School-Bibliothek gespeichert ist. Mit diesem Ansatz müssen Inhaltsersteller das semantische Modell nicht mehr veröffentlichen, um Änderungen anzuzeigen. Stattdessen werden die Änderungen nach einer automatischen OneDrive-Aktualisierung angezeigt, die stündlich auftritt. Dieser Ansatz ist zwar praktisch, bietet jedoch einige Überlegungen und kann nicht einfach rückgängig gemacht werden.

Die Versionssteuerung mit SharePoint oder OneDrive ist zwar einfach einzurichten und zu verwalten, hat jedoch mehr Einschränkungen. Beispielsweise ist es nicht möglich, Änderungen innerhalb des Inhalts anzuzeigen, und es ist auch nicht möglich, Versionen zu vergleichen. Darüber hinaus ist es nicht möglich, komplexere Prozesse zum Verwalten dieser Änderungen einzurichten (z. B. Verzweigungs- oder Pullanforderungen, die weiter unten in diesem Artikel beschrieben werden).

Erwägen Sie die Verwendung von SharePoint oder OneDrive zum Nachverfolgen und Verwalten von Änderungen in den folgenden Szenarien:

• Der Inhalt besteht aus nur semantischen Modellen oder Berichten, die als PBIX-Dateien gespeichert wurden.
• Self-Service-Benutzer erstellen und verwalten die Inhalte.
• Inhaltsersteller arbeiten mithilfe von Microsoft Teams zusammen.
• Inhaltsersteller sind mit Git und Quellcodeverwaltung unerfahren.
• Inhaltsersteller verwalten ein einzelnes Element mit eingeschränkter Komplexität und Zusammenarbeit.
• Die PBIX-Dateien haben eine Vertraulichkeitsbezeichnung angewendet, die ihre Inhalte verschlüsselt.

Hinweis

OneDrive und SharePoint unterstützen Inhalte mit angewendeten Vertraulichkeitsbezeichnungen, mit Ausnahme einiger eingeschränkter Szenarien. Im Gegensatz dazu unterstützt die Fabric Git-Integration keine Vertraulichkeitsbezeichnungen.

Vermeiden Sie die Verwendung von SharePoint oder OneDrive zum Nachverfolgen und Verwalten von Änderungen in den folgenden Szenarien:

• Inhalt besteht aus anderen Elementtypen als semantischen Modellen und Berichten.
• Der Inhalt ist komplex oder groß im Umfang.
• Inhaltsersteller müssen gleichzeitig an demselben Element zusammenarbeiten.

In den folgenden Abschnitten werden zusätzliche Überlegungen zur effektiven Verwendung der Versionssteuerung mithilfe von SharePoint oder OneDrive mit Power BI beschrieben.

Microsoft Teams-Integration

Sie können die Dokumentbibliotheken von Microsoft Teams verwenden, wenn Inhaltsersteller sie für die Zusammenarbeit verwenden. Dokumentbibliotheken sind SharePoint-Websites und die Verwendung der Dokumentbibliotheken (anstelle eines separaten SharePoint-Website- oder OneDrive-Ordners) stellt die Zentraleisierung von Inhalten, Dateien und Zusammenarbeit sicher.

Einchecken und Auschecken von Dateien

Sie sollten Dateien auschecken , an denen Sie arbeiten, um mögliche Änderungskonflikte zu vermeiden. Nachdem Die Änderungen abgeschlossen sind, checken Sie die Dateien mit Kommentaren ein, die die Änderung beschreiben. Das Einchecken und Auschecken von Dateien hilft Ihnen, die Zusammenarbeit zwischen Inhaltserstellern zu verbessern, wenn Sie SharePoint oder OneDrive for Work and School für die Versionssteuerung verwenden. Wenn Sie Dateien mit mehreren Inhaltserstellern einchecken und auschecken, können Sie die SharePoint-Websitebibliothek ändern, um die letzte Aktualisierung und die Kommentare der letzten Eincheckung anzuzeigen.

Versionsverlauf

Stellen Sie sicher, dass Sie Inhalte an einem separaten Speicherort sichern, wenn unerwartete Unterbrechungen in Ihrer SharePoint-Websitedokumentbibliothek auftreten. Sie sollten auch Grenzwerte für die Anzahl der Versionen festlegen, die auf der SharePoint-Website aufbewahrt werden, und alte Versionen löschen. Dadurch wird sichergestellt, dass der Versionsverlauf aussagekräftig bleibt und nicht zu viel Platz einnimmt.

Für eine komplexere Versionssteuerung können Sie Dateien in einem Remoterepository wie Azure Repos speichern und Änderungen mithilfe der Quellcodeverwaltung verwalten.

Quellcodeverwaltung mithilfe eines Git-Remote-Repositorys

Ein Remote-Git-Repository erleichtert die Quellcodeverwaltung von Dateien, wodurch Inhaltsersteller weitere Optionen zum Nachverfolgen und Verwalten von Änderungen ermöglichen. Kurz gesagt können Inhaltsersteller Inhalte entweder lokal oder im Power BI-Dienst entwickeln, dann commiten und diese Änderungen an ein Remote-Git-Repository wie Azure Repos oder GitHub übertragen.

Hinweis

Sie können auch die Quellcodeverwaltung Für Ihre Inhalte ausführen, ohne die Git-Integration zu verwenden. In diesem Szenario verfolgen und verwalten Sie weiterhin Inhaltsänderungen in einem Remote-Git-Repository, aber Sie stellen Inhalte mithilfe der REST-APIs oder XMLA-Lese-/Schreibendpunkte bereit. Weitere Informationen zu diesen Methoden zum Bereitstellen von Inhalten finden Sie in Phase 4: Bereitstellen von Inhalten.

Das folgende Diagramm zeigt eine allgemeine Übersicht darüber, wie Sie die Quellcodeverwaltung durchführen, indem Sie Inhalte lokal entwickeln und dann Änderungen an einem Remote-Repository durchführen, das mit einem Fabric-Arbeitsbereich mithilfe der Git-Integration synchronisiert werden kann.

Das Diagramm beschreibt die folgenden Prozesse und Komponenten.

Element	Beschreibung
	Inhaltsersteller entwickeln semantische Modelle und Berichte in ihrer lokalen Umgebung und speichern diese Modelle und Berichte als PBIP-Dateien. Inhaltsersteller können auch semantische Modelle entwickeln und Modellmetadaten speichern.
	Wenn sie bereit sind, speichern Inhaltsersteller ihre Änderungen, die sie übernehmen und in regelmäßigen Abständen an ein Remote-Git-Repository senden.
	Im Remote-Git-Repository verfolgen Inhaltsersteller Änderungen auf Objektebene, wodurch die Versionssteuerung erleichtert wird. Inhaltsersteller können auch Verzweigungen erstellen, um an Inhalten zu arbeiten, und ihre Änderungen in einer einzelnen Verzweigung mithilfe von Pullanforderungen zusammenzuführen.
	Inhaltsersteller können Inhalte aus dem Remote-Repository mithilfe der Git-Integration synchronisieren. Sie können Inhalte auch mithilfe anderer Ansätze bereitstellen, z. B. Azure-Pipelines zusammen mit den REST-APIs.
	Im Fabric-Arbeitsbereich sehen Inhaltsersteller die Änderungen an Power BI-Inhalten nach Abschluss der Synchronisierung oder Bereitstellung. Inhaltsersteller können Inhalte wie Datenflüsse oder Notizbücher im Arbeitsbereich erstellen. Wenn sie die Git-Integration verwenden, verknüpfen Inhaltsersteller diesen Arbeitsbereich mit einer bestimmten Verzweigung des Remote-Repositorys.
	Inhaltsersteller können Änderungen von einem Arbeitsbereich in das Remote-Repository mithilfe der Git-Integration übernehmen und pushen. Diese Änderungen können Elementdefinitionen für unterstützte Inhalte importieren, die im Arbeitsbereich erstellt wurden, z. B. Datenflüsse und Notizbücher.

Zusammenfassend speichern Inhaltsersteller PBIP-Dateien, Metadatendateien und Dokumentationen in einem zentralen Azure Repos-Remote-Repository. Diese Dateien werden von einem technischen Besitzer zusammengestellt. Während ein Inhaltsersteller eine Lösung entwickelt, ist ein technischer Besitzer für die Verwaltung der Lösung und Überprüfung der Änderungen sowie deren Zusammenführung in einer einzigen Lösung verantwortlich. Azure Repos bietet im Vergleich zu SharePoint und OneDrive ausgefeiltere Optionen zum Nachverfolgen und Verwalten von Änderungen. Die Pflege eines sorgfältig kuratierten, dokumentierten Repositorys ist von entscheidender Bedeutung, da es die Grundlage aller Inhalte und der Zusammenarbeit ist.

Erwägen Sie die Verwendung der Quellcodeverwaltung zum Nachverfolgen und Verwalten von Änderungen in den folgenden Szenarien:

• Zentrale oder dezentrale Teams erstellen und verwalten die Inhalte.
• Inhaltsersteller arbeiten mit Azure DevOps zusammen.
• Inhaltsersteller sind mit Git-, Quellcodeverwaltungs- oder DataOps-Prinzipien vertraut.
• Inhaltsersteller verwalten komplexe oder wichtige Inhalte oder erwarten, dass die Inhalte in Komplexität und Wichtigkeit skaliert und vergrößert werden.

Im Folgenden finden Sie einige Voraussetzungen und Überlegungen, die Ihnen bei der effektiven Verwendung der Quellcodeverwaltung mit Azure DevOps helfen.

• Git: Um Änderungen zu committen und an ein Remoterepository zu pushen, müssen Inhaltsersteller Githerunterladen und installieren. Git ist ein verteiltes Versionskontrollsystem, das Änderungen in Ihren Dateien nachverfolgt. Informationen zu Git-Grundlagen finden Sie unter Was ist Git?.
• Tools: Um Git zu verwenden, müssen Inhaltsersteller entweder eine Befehlszeilenschnittstelle (CLI) oder einen GUI-Client (Grafische Benutzeroberfläche) für SCM verwenden, z. B. Visual Studio oder Visual Studio Code.
• Lizenzen und Berechtigungen: Um ein Azure Repos Git-Repository zu erstellen und zu verwenden, müssen Inhaltsersteller folgendes haben:
  • Zugriffsebene auf "Basis" (im Gegensatz zu Stakeholder) festgelegt.
  • Gehören Sie zu einer Organisation und einem Projekt.
  • Entsprechende Repository-Berechtigungen.
• Fabric Git-Integration: Um Inhalte in einem Remote-Repository mit einem Microsoft Fabric-Arbeitsbereich zu synchronisieren, verwenden Inhaltsersteller die Fabric Git-Integration. Dies ist wichtig, um Änderungen an Inhalten, die im Fabric-Portal erstellt wurden, wie z. B. Datenflüsse, nachzuverfolgen und zu verwalten.

Tipp

Um die Quellcodeverwaltung mit der lokalen Entwicklung zu erleichtern, empfehlen wir die Verwendung einer Clientanwendung wie Visual Studio Code. Sie verwenden Power BI Desktop, um Inhalte zu entwickeln. Anschließend können Sie Visual Studio Code verwenden, um die Versionsverwaltung dieser Inhalte durchzuführen, indem Sie Änderungen für Ihr Remote-Repository vorbereiten, übernehmen und übertragen.

Warnung

Die Fabric Git-Integration hat einige Einschränkungen bei den unterstützten Elementen und Szenarien. Stellen Sie sicher, dass Sie zuerst überprüfen, ob die Fabric Git-Integration ihrem jeweiligen Szenario am besten entspricht, oder ob Sie einen anderen Ansatz zum Implementieren der Quellcodeverwaltung ergreifen sollten.

Darüber hinaus werden Vertraulichkeitsbezeichnungen bei der Fabric Git-Integration nicht unterstützt, und das Exportieren von Elementen mit Vertraulichkeitsbezeichnungen ist möglicherweise deaktiviert. Wenn Ihre Inhalte Über Vertraulichkeitsbezeichnungen verfügen, sollten Sie planen, wie Sie die Versionsverwaltung erreichen können, während Sie ihre Richtlinien zur Verhinderung von Datenverlust berücksichtigen.

Ein wichtiger Vorteil der Verwendung der Quellcodeverwaltung mit Azure Repos oder GitHub ist eine verbesserte Zusammenarbeit zwischen Inhaltserstellern und mehr Anpassungen und Übersicht über Inhaltsänderungen und die Bereitstellung.

Das folgende Diagramm zeigt eine allgemeine Übersicht darüber, wie Azure DevOps die Zusammenarbeit mit der Quellcodeverwaltung ermöglicht. Sie können auch GitHub Enterprise anstelle von AzureDevOps verwenden, was verschiedene Dienste umfassen würde, die eine ähnliche Funktion ausführen.

Hinweis

Das vorherige Diagramm zeigt ein Beispiel für die Zusammenarbeit mithilfe von Azure DevOps. Wählen Sie einen Ansatz aus, der den Anforderungen und der Arbeitsweise Ihres Teams am besten entspricht.

Das Diagramm zeigt die folgenden Benutzeraktionen, Prozesse und Features.

Element	Beschreibung
	Inhaltsersteller*innen erstellen einen neuen, kurzlebigen Branch durch Klonen des Hauptbranches, der die neueste Version des Inhalts enthält. Die neue Verzweigung wird häufig als Featurezweig bezeichnet, da sie verwendet wird, um ein bestimmtes Feature zu entwickeln oder ein bestimmtes Problem zu beheben.
	Der Inhaltsersteller committet seine Änderungen während der Entwicklung in ein lokales Repository.
	Der Inhaltsersteller verknüpft seine Änderungen mit Arbeitselementen, die in Azure Boards verwaltet werden. Arbeitselemente beschreiben bestimmte Entwicklungen, Verbesserungen oder Fehlerbehebungen, die auf den Bereich ihres Branch bezogen sind.
	Der Inhaltsersteller committet seine Änderungen regelmäßig. Wenn er bereit ist, veröffentlicht der Inhaltsersteller seinen Branch im Remote-Repository.
	Zum Testen der Änderungen stellen Inhaltsersteller*innen ihre Lösung in einem isolierten Arbeitsbereich für ihre Entwicklung bereit (in diesem Diagramm nicht dargestellt). Inhaltsersteller*innen können den Featurebranch auch mithilfe der Fabric Git-Integration mit dem Arbeitsbereich synchronisieren.
	Inhaltserstellende und Inhaltsbesitzer dokumentieren die Lösung und ihre Prozesse in einem Azure Wiki, das dem gesamten Entwicklungsteam zur Verfügung steht.
	Wenn sie bereit sind, öffnen Inhaltsersteller*innen einen Pull Request, um den Featurebranch in den Hauptbranch zusammenzuführen.
	Ein technischer Besitzer ist für die Überprüfung des Pull Requests und das Zusammenführen von Änderungen verantwortlich. Wenn er den Pull Request genehmigt, führt er den Featurebranch im Hauptbranch zusammen.
	Eine erfolgreiche Zusammenführung löst die Bereitstellung der Lösung in einem Entwicklungsarbeitsbereich mithilfe einer Azure-Pipeline aus (in diesem Diagramm nicht dargestellt). Bei Verwendung der Fabric Git-Integration wird der Hauptbranch mit dem Entwicklungsarbeitsbereich synchronisiert.
	Der Releasemanager führt eine abschließende Überprüfung und Genehmigung der Lösung durch. Diese Releasegenehmigung verhindert, dass die Lösung veröffentlicht wird, bevor sie bereit ist. Bei der Veröffentlichung von Unternehmensinhalten planen und koordinieren Releasemanager*innen in der Regel die Inhaltsfreigabe für Test- und Produktionsumgebungen. Sie koordinieren und kommunizieren mit Inhaltserstellenden, Projektbeteiligten und Benutzern.
	Wenn der Releasemanager das Release genehmigt, bereitet Azure Pipelines die Lösung automatisch für die Bereitstellung vor. Alternativ kann eine Azure-Pipeline auch eine Bereitstellungspipeline auslösen, um Inhalte zwischen Arbeitsbereichen höher zu stufen.
	Benutzer*innen testen und überprüfen Inhalte im Testarbeitsbereich. Wenn Sie die Git-Integration mit Azure Pipelines für die Bereitstellung verwenden, wird der Testarbeitsbereich mit keiner Branch synchronisiert.
	Nachdem Benutzer*innen Änderungen akzeptiert und überprüft haben, führen Releasemanager*innen eine endgültige Überprüfung und Genehmigung der Lösung für die Bereitstellung im Produktionsarbeitsbereich durch.
	Benutzer*innen zeigen Inhalte an, die im Produktionsarbeitsbereich veröffentlicht werden. Wenn Sie die Git-Integration mit Azure Pipelines für die Bereitstellung verwenden, wird der Produktionsarbeitsbereich mit keiner Branch synchronisiert.

In den folgenden Abschnitten werden zusätzliche Überlegungen zur effektiven Verwendung der Quellcodeverwaltung mithilfe von Azure DevOps und Power BI beschrieben.

Von Bedeutung

Die effektive Nutzung von Branching, Commits, Pull Requests und Merges ist entscheidend, um den maximalen Nutzen aus der Versionsverwaltung zu ziehen, wenn Sie den Lebenszyklus Ihrer Power BI-Inhalte managen.

Verwenden von Verzweigungen

Inhaltsersteller erreichen die Zusammenarbeit mithilfe einer Verzweigungsstrategie. Eine Verzweigungsstrategie ermöglicht es einzelnen Inhaltserstellern, isoliert in ihrem lokalen Repository zu arbeiten. Wenn sie bereit sind, kombinieren sie ihre Änderungen zu einer einzigen Lösung im Remote-Repository. Inhaltserstellende sollten ihre Arbeit auf Branches festlegen, indem sie sie für bestimmte Entwicklungen, Verbesserungen oder Fehlerbehebungen mit Arbeitselementen verknüpfen. Jeder Inhaltsersteller erstellt einen eigenen Branch des Remote-Repositorys für seinen Arbeitsbereich. Die Arbeit an der lokalen Lösung wird zugesichert und mit einer beschreibenden Commit-Nachricht an eine Version des Zweigs im Remote-Repository gepusht. Eine Commitnachricht beschreibt die Änderungen, die in diesem Commit vorgenommen wurden.

Wenn Sie eine Verzweigungsstrategie zum Verwalten von Fabric-Inhalten verwenden, berücksichtigen Sie die folgenden Faktoren.

• Welche Zweig von Inhaltsautoren für ihre eigene Arbeit geklont werden sollte. Wenn es sich bei diesen Verzweigungen beispielsweise um einen Klon der Hauptverzweigung (als trunkbasierte Entwicklung bezeichnet) oder um andere Verzweigungen handelt, z. B. Release-Verzweigungen für bestimmte, geplante Inhaltsversionen.
• Gibt an, ob Sie bestimmte Aufgaben auf unterschiedliche Inhaltsversionen beschränken, indem Sie Release-Verzweigungen verwenden.
• Welche Branches verbinden sich mit welchem Arbeitsbereich bei Verwendung der Fabric Git-Integration?

Tipp

Unter "Einführung einer Git Branching-Strategie" finden Sie spezifische Anleitungen und Empfehlungen zur optimalen Verwendung einer Verzweigungsstrategie, um die Zusammenarbeit effektiv zu erleichtern.

Batchänderungen in Commits

Während der Entwicklung von Inhalten sollten Ersteller von Inhalten regelmäßig Änderungen in Batches (oder Gruppen) zusammenfassen. Diese Änderungen sollten eine bestimmte Arbeitsaufgabe für die Lösung behandeln (z. B. ein Feature oder Problem). Wenn sie bereit sind, übernehmen Inhaltsersteller diese mehrstufigen Änderungen.

Batchweise Änderungen auf diese Weise durchzuführen, bietet mehrere Vorteile.

• Sie hilft bei der Strukturentwicklung und bietet Inhaltserstellern die Möglichkeit, die von ihnen gruppierten Änderungen zu überprüfen und zu dokumentieren.
• Es verbessert die Ausrichtung zwischen Planung und Entwicklung, erleichtert das Verknüpfen von Features und Themen und schafft Transparenz darüber, wie die Arbeit voranschreitet.
• Technische Verantwortliche können die Pull-Requests der Inhaltsersteller leichter überprüfen, wenn die Änderungen entsprechend gebündelt und klare Commit-Nachrichten vorhanden sind.

Berücksichtigen Sie beim Stufen und Übernehmen von Änderungen an Power BI-Inhalten die folgenden Faktoren.

• Egal, ob Sie Änderungen aus einem lokalen Repository oder dem Fabric-Arbeitsbereich stagen und committen.
• Platzieren Sie PBIP-Dateien in Ordnern der obersten Ebene, wenn Sie mehrere Modelle oder Berichte in einem einzigen Repository speichern. Dies erleichtert das Identifizieren und Gruppieren von Änderungen, die Sie vornehmen.
• Ignorieren Sie unauffällige oder nicht hilfreiche Metadatenänderungen mithilfe einer Gitignore-Datei oder einer GITATTRIBUTEs-Datei. Dadurch wird sichergestellt, dass alle Änderungen, die Sie übernehmen, aussagekräftig sind.

Tipp

Unter "Speichern Ihrer Arbeit mit Commits " finden Sie spezifische Anleitungen und Empfehlungen zum Bereitstellen und Übernehmen Ihrer Arbeit an ein Git-Repository.

Erstellen von Pullanforderungen zum Zusammenführen von Änderungen

Um die Änderungen zusammenzuführen, öffnet ein Inhaltsersteller einen Pull Request. Ein Pull Request ist eine Übermittlung für die Peerüberprüfung, die zur Zusammenführung der ausgeführten Arbeit in einer einzelnen Lösung führen kann. Das Zusammenführen kann zu Konflikten führen, die aufgelöst werden müssen, bevor der Branch zusammengeführt werden kann. Pull Request-Überprüfungen sind wichtig, um sicherzustellen, dass Ersteller die Organisationsstandards und -methoden für Entwicklung, Qualität und Compliance einhalten.

Wenn Sie Pullanforderungen zum Zusammenführen von Änderungen an Power BI-Inhalten verwenden, berücksichtigen Sie die folgenden Faktoren.

• Welche Standards und Methoden Sie verwenden werden, um Ihre Überprüfung durchzuführen, falls vorhanden. Sie können z. B. Regeln aus dem Best Practice Analyzer für semantische Modelle verwenden.
• Wie Sie Änderungen an Berichtsmetadaten überprüfen, was nicht einfach zu lesen und zu verstehen ist, ohne Tools von Drittanbietern zu verwenden.
• Wie Sie Zusammenführungskonflikte angehen und lösen.

Tipp

Informationen zu Pull Requests und Zusammenführungsstrategien und Squash-Merge für spezifische Anleitung und Empfehlungen zur optimalen Nutzung von Pull Requests, um die Zusammenarbeit durch das Zusammenführen von Inhaltsänderungen zu optimieren.

Prüfliste – Bei der Planung, wo Sie Dateien speichern, umfassen wichtige Entscheidungen und Aktionen:

• Wählen Sie Ihre Entwicklungstools aus: Stellen Sie sicher, dass Ihr Ansatz zum Entwickeln von Inhalten mit der Zusammenarbeit mit anderen Inhaltserstellern übereinstimmt und die Versionssteuerung verwendet.
• Wählen Sie zwischen PBIP- und PBIX-Formaten für Modelle und Berichte aus: In der Regel ist das PBIP-Format für die Quellcodeverwaltung vorteilhafter, aber Self-Service-Benutzer können PBIX-Dateien einfacher finden.
• Separates Semantikmodell und Berichtsentwicklung: Die Versionssteuerung ist am effektivsten, wenn Sie Änderungen für verschiedene Elementtypen separat verwalten. Das Trennen von Modell- und Berichtsentwicklung wird als bewährte Methode angesehen.
• Entscheiden Sie, wie viele Arbeitsbereiche Sie benötigen: Die Verwendung separater Umgebungen ist für den Erfolg der Inhaltslebenszyklusverwaltung von entscheidender Bedeutung. Stellen Sie sicher, dass Sie klargestellt haben, wie viele Arbeitsbereiche Sie benötigen, und führen Sie eine geeignete Planung auf Arbeitsbereichsebene durch.
• Entscheiden Sie, wie Sie die Versionssteuerung implementieren: Entscheiden Sie zwischen einem einfacheren Ansatz mithilfe von SharePoint oder OneDrive for Business oder mithilfe von Azure DevOps, um die Quellcodeverwaltung zu vereinfachen.
• Richten Sie Ihr Remote-Repository ein: Erstellen Sie einen strukturierten Bereich im OneDrive-Ordner oder Git Repo, in dem Sie Inhalte speichern, um Änderungen nachzuverfolgen und zu verwalten.
• Wenn Sie die Quellcodeverwaltung verwenden, richten Sie GITIGNORE- und GITATTRIBUTES-Dateien ein: Stellen Sie sicher, dass Sie Ihr Repository so einrichten, dass Sie nur sinnvolle Änderungen nachverfolgen.
• Wenn Sie die Quellcodeverwaltung verwenden, definieren Sie Verzweigungs- und Zusammenführungsstrategien: Stellen Sie sicher, dass Sie klare Prozesse für die Einrichtung und Verwendung der Quellcodeverwaltung definieren, um die Entwicklung optimal zu unterstützen. Vermeiden Sie es, den Prozess zu überkomplizieren. Versuchen Sie stattdessen, die aktuelle Arbeitsweise in Ihren Entwicklungsteams zu ergänzen.

Verwandte Inhalte

Im nächsten Artikel dieser Reihe erfahren Sie, wie Sie Inhalte im Rahmen der Verwaltung des Inhaltslebenszyklus überprüfen.