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

Dieser Artikel hilft Ihnen bei der Entwicklung von Inhalten und der Verwaltung von Änderungen im Rahmen der Verwaltung des Lebenszyklus von Inhalten. Er wendet sich in erster Linie an folgende Zielgruppen:

• COE-Teams (Center of Excellence) und BI-Teams: Die Teams, die für 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, welche den Lebenszyklus von Inhaltsreleases behandeln, oder Techniker, welche die Komponenten erstellen und verwalten, die für die effektive Nutzung und den Support der Lebenszyklusverwaltung erforderlich sind.
• Inhaltsersteller und Inhaltsbesitzer: Benutzer, die Inhalte erstellen, die sie im Fabric-Portal veröffentlichen wollen, um sie für andere Personen freizugeben. Diese Personen sind für die Verwaltung des Lebenszyklus der von ihnen erstellten Power BI-Inhalte verantwortlich.

Lebenszyklusverwaltung umfasst die Prozesse und Methoden, die Sie verwenden, um Inhalte von der Erstellung bis zur späteren Veralterung zu behandeln. In der ersten Phase der Lebenszyklusverwaltung planen und entwerfen Sie Inhalte, was die Lösungsplanung und das Treffen wichtiger Entscheidungen beinhaltet, 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 eine stabile und konsistente Bereitstellung von Inhalten für Konsumenten sicherzustellen.

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

Inhaltsersteller und -besitzer sollten Inhaltsänderungen mithilfe der Versionskontrolleverwalten. Die Versionskontrolle ist die Methode zum Verwalten von Änderungen an Dateien oder Code in einem zentralen Repository. Diese Praxis unterstützt eine effektivere Zusammenarbeit und Inhaltsverwaltung.

Weitere Vorteile der Versionskontrolle sind folgende:

• Zusammenführen von Änderungen mehrerer Inhaltsersteller und Behandeln von Zusammenführungskonflikten.
• Identifizieren, welche Inhalte geändert wurden und welche Änderungen in diesen Inhalten vorgenommen wurden.
• Verknüpfen von Inhaltsänderungen mit bestimmten Arbeitselementen.
• Gruppieren von Änderungen in unterschiedliche Releases mit Versionsverlauf.
• Zurücksetzen von Änderungen oder ganzen Versionen von Inhalten.

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

Entscheiden Sie, wie Sie Inhalte entwickeln wollen

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

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 der folgenden wichtigen Entscheidungen treffen:

• Welches Dateiformat soll verwendet werden: Sie können Inhalte entweder als PBIX- oder PBIP-Dateien speichern. Die Git-Integration erfordert beispielsweise, dass Sie PBIP-Dateien verwenden, aber Self-Service-Ersteller finden PBIX-Dateien in Teams, SharePoint oder OneDrive möglicherweise einfacher zu verwalten und zu pflegen.
• Verwalten von benutzerdefinierten Inhalten: Sie können Themen, benutzerdefinierte Visuals oder Bilder zu Power BI Desktop-Dateien hinzufügen, was möglicherweise unterschiedliche Überlegungen zur Lebenszyklusverwaltung erfordert. Wenn Inhaltsersteller beispielsweise eigene benutzerdefinierte Visuals erstellen, sollten sie die Visualdefinition in einer separaten Datei speichern und verwalten.
• Verwalten von Previewfunktionen: Sie können sich für die Vorschaufeatures oder Vorschaueinstellungen in Power BI Desktop entscheiden, wodurch sich der Inhalt und die Art der Nutzung ändert. Beispielsweise könnten Sie zusätzliche Schritte ausführen, um Inhalte zu überprüfen, die Previewfunktionen verwenden.

Webdokumenterstellung

Bestimmte Inhalte – z. B. Dataflows, Dashboards und Scorecards – können nur im Fabric-Portal erstellt werden. Sie können einige 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 Webdokumenterstellung sollten Sie einige der folgenden wichtigen Entscheidungen treffen:

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

Weitere Tools

Sie können andere Tools zum Erstellen oder Verwalten bestimmter Inhaltstypen verwenden. Diese Tools können zusätzliche Nutzen bieten, besser zu Ihrem Workflow passen oder für die Verwaltung bestimmter Funktionen oder Inhaltstypen erforderlich sein. 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 folgende.

• 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) durchführen, indem lokale Änderungen an ein Remoterepository committet und gepusht werden.
• Tabellarischer Editor: Ein Drittanbietertool zum Entwickeln und Verwalten semantischer Modelle.
• Excel: Ein Clienttool für PivotTables und live verbundene Tabellen, die mit einem semantischen Modell arbeiten.
• Power BI Report Builder: Eine Desktopanwendung zum Erstellen von paginierten Berichtsdateien (RDL).

Beim Erstellen von Inhalten mithilfe anderer Tools sollten Sie einige der folgenden wichtigen 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. die Verwendung von XMLA-Endpunkten oder Power BI-REST-APIs.

Wenn Sie sich entschieden haben, wie Sie Inhalte erstellen werden, müssen Sie als Nächstes entscheiden, wo Sie Inhalte veröffentlichen und testen, während Sie diese entwickeln.

Entscheiden, wie Sie Arbeitsbereiche einrichten und verwenden werden

Beim Entwickeln von Inhalten sollten Sie mehrere Arbeitsbereiche (oder Stages) verwenden, um Produktionsinhalte, die von der Organisation verwendet werden, von Inhalten zu trennen, die entwickelt oder geprü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. Auf diese Weise 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. Auf diese Weise wird vermieden, dass die für die Entwicklung und das Testen verwendeten Ressourcen Produktionsworkloads stören und zu langsamen Datenaktualisierungen oder Berichten führen.
• Sie können einen strukturierteren Prozess für die Entwicklung, das Testen und die Freigabe von Inhalten schaffen, indem Sie für jede dieser Stages eine eigene Umgebung einrichten. Dies hilft Ihnen, die Produktivität zu verbessern.

Für Fabric und Power BI empfehlen wir, separate Fabric-Arbeitsbereiche zu verwenden, wie in den Planungsartikeln auf Mandantenebene und Arbeitsbereichsebene beschrieben.

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 ihres 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 wird Zugriff auf jeden Arbeitsbereich haben?
• Gehören die Arbeitsbereiche zu einer Fabric-Bereitstellungspipeline, oder werden Sie die Bereitstellung mithilfe anderer Ansätze orchestrieren, z. B. mithilfe von Azure Pipelines?
• Wie werden Sie die arbeitsbereichübergreifende Veröffentlichung verwalten? 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?
• Müssen Sie auch separate unterstützende Ressourcen für Elemente in Produktionsarbeitsbereichen verwenden, z. B. einen separaten lokalen Datengatewaycluster?

Die folgenden Abschnitte geben eine allgemeine Übersicht über die verschiedenen Ansätze zur Trennung von Arbeitsbereichen, um die Lebenszyklusverwaltung zu unterstützen.

Test- und Produktionsarbeitsbereiche

Wenn Sie einfachere Inhalte bereitstellen, die für die Organisation nicht kritisch sind, reichen zwei Arbeitsbereiche häufig aus. In diesem Szenario arbeiten die Inhaltsersteller in der Regel nur in begrenztem Umfang an denselben Objekten zusammen und entwickeln die Inhalte lokal.

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

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 mit der Webdokumenterstellung erstellt werden können und führen die Inhaltsprüfung im Testarbeitsbereich durch.
	Wenn sie bereit sind, stellen Inhaltsersteller die Inhalte in einem Produktionsarbeitsbereich bereit. Im Produktionsarbeitsbereich verteilen Inhaltsersteller die Inhalte, indem sie eine Power BI-App veröffentlichen oder Inhalte aus dem Arbeitsbereich freigeben.

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 einfaches Beispiel dafür, wie Sie separate Umgebungen mit einem Entwicklungs-, Test- und Produktionsarbeitsbereich verwenden könnten.

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 Webdokumenterstellung erstellt werden können. Inhaltsersteller können Inhalte auch im Entwicklungsarbeitsbereich prüfen.
	Wenn sie bereit sind, stellen Inhaltsersteller die Inhalte in einem Testarbeitsbereich bereit. Im Testarbeitsbereich prüfen Benutzer Inhalte entweder im Arbeitsbereich selber oder in einer App.
	Wenn sie bereit sind, stellen Inhaltsersteller die Inhalte in einem Produktionsarbeitsbereich bereit. Im Produktionsarbeitsbereich verteilen Inhaltsersteller die Inhalte, indem sie eine Power BI-App veröffentlichen oder Inhalte aus dem Arbeitsbereich freigeben.

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 das Testen von Inhalten im Fabric-Portal oder die Verwendung von Features wie der geplanten Aktualisierung, ohne Unterbrechungen für andere Personen im Entwicklungsteam zu riskieren. Inhaltsersteller können hier auch Inhalte im Fabric-Portal entwickeln, z. B. Dataflows. Private Arbeitsbereiche können eine gute Wahl sein, wenn Sie Inhaltsänderungen mithilfe der Git-Integration zusammen mit Azure DevOps verwalten.

Das folgende Diagramm zeigt ein einfaches Beispiel, wie Sie separate Umgebungen mithilfe eines privaten Arbeitsbereichs mit Git-Integration verwenden könnten.

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

Element	Beschreibung
	Jeder Inhaltsersteller entwickelt Inhalte in seiner eigenen lokalen Umgebung.
	Wenn sie bereit sind, committen und pushen Inhaltsersteller ihre Änderungen an ein Remoterepository, z. B. ein Azure Repos Git-Repository.
	Im Git-Remoterepository können Inhaltsersteller Inhaltsänderungen mithilfe der Quellcodeverwaltung nachverfolgen und verwalten sowie Inhalte verzweigen und zusammenführen, um die Zusammenarbeit zu unterstützen.
	Inhaltsersteller synchronisieren einen Branch des Remoterepositorys mit einem privaten Arbeitsbereich. Nach der Synchronisierung sind die neuesten Änderungen, die ein Ersteller an den Branch committet und pusht, in diesem privaten Arbeitsbereich sichtbar. Verschiedene Inhaltsersteller arbeiten in ihren eigenen, separaten Branches, während sie Änderungen vornehmen.
	In den privaten Arbeitsbereichen können Inhaltsersteller Inhalte mithilfe der Webdokumenterstellung entwickeln und ihre eigenen Änderungen prüfen. Änderungen an Inhalten, die mit der Webdokumenterstellung vorgenommen werden, können mit dem Branch im Git-Repository synchronisiert werden, wenn der Inhaltsersteller diese Änderungen committet und aus dem Arbeitsbereich pusht. Verschiedene Inhaltsersteller arbeiten in ihren eigenen, separaten privaten Arbeitsbereichen.
	Wenn sie bereit sind, führen Inhaltsersteller einen Pull Request aus, um ihre Änderungen in den Hauptbranch der Lösung zusammenzuführen.
	Nach dem Zusammenführen von Änderungen synchronisiert sich der Hauptbranch mit dem Entwicklungsarbeitsbereich.
	Im Entwicklungsarbeitsbereich können Inhaltsersteller Inhalte entwickeln, die von der Fabric Git-Integration nicht unterstützt werden, z. B. Dashboards. Inhaltsersteller prüfen auch die integrierte Lösung, welche alle neuesten Änderungen enthält.
	Wenn sie bereit sind, stellen Inhaltsersteller die Inhalte in einem Testarbeitsbereich bereit. Im Testarbeitsbereich führen Benutzer Akzeptanztests von Inhalten durch.
	Wenn sie bereit sind, stellen Inhaltsersteller die Inhalte in einem Produktionsarbeitsbereich bereit. Im Produktionsarbeitsbereich verteilen Inhaltsersteller die Inhalte, indem sie eine Power BI-App veröffentlichen oder Inhalte aus dem Arbeitsbereich freigeben.

Unterstützen von 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 diese auch in dieselbe Anzahl von Stages aufteilen müssen, oder wie Sie anderenfalls die Verwendung in diesen Umgebungen koordinieren werden.

• Gateways: Erwägen Sie die Verwendung separater lokaler Datengatewayclusters und VNet-Gateways für Produktionsworkloads. Dies ist von Vorteil, um Unterbrechungen zu verhindern, aber auch, um die Uptime 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 Stages bereitzustellen oder zu kopieren. Apps im Testarbeitsbereich sollen Ihnen dabei helfen, Inhalte und die App-Erfahrung zu testen, bevor Sie Änderungen im Produktionsarbeitsbereich bereitstellen. Apps im Produktionsarbeitsbereich sollen Inhalte für Endbenutzer in einer strukturierten Erfahrung bereitstellen.
• Azure DevOps: Wenn Sie Azure DevOps für die Zusammenarbeit und die Orchestrierung der Quellcodeverwaltung und der Bereitstellung verwenden möchten, überlegen Sie, wie Sie Branches und Azure Pipelines verwenden werden, 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 werden, besteht der nächste Schritt darin, zu entscheiden, wie Sie die Versionskontrolle durchführen werden, um Inhaltsänderungen nachzuverfolgen und zu verwalten.

Entscheiden, wie Sie die Versionskontrolle verwenden werden

In Power BI können Sie die Versionsverwaltung entweder mithilfe von SharePoint/OneDrive oder mithilfe eines Git-Remoterepositorys wie Azure Repos durchführen, das eine Komponente von Azure DevOps ist. In beiden Ansätzen fügen Sie lokale Inhaltsdateien zu einem Remotespeicherort hinzu, um Änderungen nachzuverfolgen und zu verwalten. Wir empfehlen, SharePoint oder OneDrive nur für kleinere und einfachere Projekte zu verwenden, da sie nicht über die Funktionen und die Robustheit verfügen, um größere oder kompliziertere Szenarien zu unterstützen.

Hier sind einige allgemeine Überlegungen, die Ihnen beim Einrichten und Verwenden der Versionskontrolle helfen.

• Warnungen: Sie sollten Warnungen einrichten, wenn andere Personen kritische Dateien hinzufügen, entfernen oder ändern.
• Bereich: Definieren Sie den Bereich des Remotespeicherorts eindeutig. Im Idealfall ist der Bereich des Remotespeicherorts identisch mit dem Bereich der nachgelagerten Arbeitsbereiche und Apps, die Sie zum Bereitstellen von Inhalten an Konsumenten verwenden.
• Zugriff: Sie sollten den Zugriff auf den Remotespeicherort mithilfe eines ähnlichen Berechtigungsmodells einrichten, wie Sie es für Ihre Berechtigungen der Bereitstellungspipeline 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.

Die folgenden Abschnitte beschreiben die einzelnen Ansätze und wichtigsten Überlegungen, um zu entscheiden, welchen Ansatz Sie verwenden sollten.

Versionskontrolle mithilfe von SharePoint oder OneDrive für Arbeit und Schule

SharePoint verfügt über eine integrierte Versionskontrolle für Dateien. Inhaltsersteller können semantische Modelle oder Berichte lokal entwickeln, und ihre Änderungen werden mit einer Dokumentbibliothek von SharePoint oder OneDrive für Arbeit und Schule synchronisiert.

Das folgende Diagramm zeigt eine allgemeine Übersicht über die Durchführung der Versionskontrolle 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 Remotebibliothek von SharePoint oder OneDrive für Arbeit und Schule synchronisieren.
	In der Remotebibliothek verfolgen Inhaltsersteller Änderungen auf Dateiebene, wodurch die Versionskontrolle unterstützt wird.
	Inhaltsersteller können ein veröffentlichtes Semantikmodell oder einen Bericht mit einer PBIX-Datei verknüpfen, um die OneDrive-Aktualisierung zu unterstützen. 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.

Inhaltsersteller können ein veröffentlichtes Semantikmodell oder einen Bericht mit einer PBIX-Datei verknüpfen, die in einer Bibliothek von SharePoint oder OneDrive für Arbeit und Schule gespeichert ist. Mit diesem Ansatz müssen Inhaltsersteller das semantische Modell nicht mehr veröffentlichen, um Änderungen anzuzeigen. Stattdessen werden die Änderungen nach einer stündlich durchgeführten automatischen OneDrive-Aktualisierung sichtbar sein. Dieser Ansatz ist zwar bequem, erfordert jedoch einige Überlegungen und kann nicht einfach rückgängig gemacht werden.

Die Versionskontrolle 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. Außerdem ist es nicht möglich, ausgefeiltere Prozesse zur Verwaltung dieser Änderungen einzurichten (wie z.B. Branching oder Pull Requests, die später 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 sind.
• Self-Service-Benutzer erstellen und verwalten die Inhalte.
• Inhaltsersteller arbeiten mithilfe von Microsoft Teams zusammen.
• Inhaltsersteller haben keine Erfahrung mit Git und der Quellcodeverwaltung.
• Inhaltsersteller verwalten ein einzelnes Element mit eingeschränkter Komplexität und Zusammenarbeit.
• Die PBIX-Dateien haben eine Vertraulichkeitsbezeichnung angewendet, die ihre Inhalte verschlüsselt.

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

• Der Inhalt besteht aus anderen Elementtypen als semantischen Modellen und Berichten.
• Der Inhalt ist komplex oder groß im Bereich.
• Inhaltsersteller müssen gemeinsam und zur gleichen Zeit an demselben Element arbeiten.

Die folgende Abschnitten beschreiben zusätzliche Überlegungen zur effektiven Verwendung der Versionskontrolle mithilfe von SharePoint oder OneDrive mit Power BI.

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 einer separaten SharePoint-Website oder eines OneDrive-Ordners) stellt die Zentralisierung von Inhalten, Dateien und der 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, welche die Änderung beschreiben. Das Einchecken und Auschecken von Dateien hilft Ihnen, die Zusammenarbeit zwischen Inhaltserstellern zu verbessern, wenn Sie SharePoint oder OneDrive für Arbeit und Schule für die Versionskontrolle verwenden. Wenn Sie Dateien mit mehreren Inhaltserstellern ein- und auschecken, können Sie die SharePoint-Websitebibliothek ändern, um die letzte Aktualisierung und die Kommentare des letzten Eincheckens anzuzeigen.

Versionsverlauf

Stellen Sie sicher, dass Sie den Inhalt an einem separaten Speicherort sichern, falls es zu unerwarteten Unterbrechungen in Ihrer SharePoint-Site-Dokumentenbibliothek kommt. Sie sollten auch die Anzahl der auf der SharePoint-Website gespeicherten Versionen begrenzen und alte Versionen löschen. Dadurch wird sichergestellt, dass der Versionsverlauf aussagekräftig bleibt und nicht zu viel Platz beansprucht.

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

Quellcodeverwaltung mithilfe eines Git-Remoterepositorys

Ein Git-Remoterepository unterstützt die Quellcodeverwaltung von Dateien, was Inhaltserstellern weitere Optionen zum Nachverfolgen und Verwalten von Änderungen zur Verfügung stellt. Kurz gesagt können Inhaltsersteller Inhalte entweder lokal oder im Power BI-Dienst entwickeln und diese Änderungen dann an ein Git-Remoterepository wie Azure Repos committen oder pushen.

Das folgende Diagramm zeigt eine allgemeine Übersicht über die Durchführung der Quellcodeverwaltung mittels

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 committen und in regelmäßigen Abständen an ein Git-Remoterepository pushen.
	Im Git-Remoterepository verfolgen Inhaltsersteller Änderungen auf Objektebene, was die Versionskontrolle unterstützt. Inhaltsersteller können auch Branches erstellen, um an Inhalten zu arbeiten, und ihre Änderungen in einem einzelnen Branch mithilfe von Pull Requests zusammenzuführen.
	Inhaltsersteller können Inhalte aus dem Remoterepository 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 Dataflows oder Notebooks im Arbeitsbereich erstellen. Wenn sie die Git-Integration verwenden, verknüpfen Inhaltsersteller diesen Arbeitsbereich mit einem bestimmten Branch des Remoterepositorys.
	Inhaltsersteller können Änderungen von einem Arbeitsbereich in das Remoterepository mithilfe der Git-Integration committen und pushen. Diese Änderungen können Elementdefinitionen für unterstützte Inhalte importieren, die im Arbeitsbereich erstellt wurden, z. B. Dataflows und Notebooks.

Zusammenfassend: Inhaltsersteller speichern PBIP-Dateien, Metadatendateien und Dokumentationen in einem zentralen Azure Repos-Remoterepository. 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 Prinzipien von Git, der Quellcodeverwaltung oder DataOps vertraut.
• Inhaltsersteller verwalten komplexe oder wichtige Inhalte oder erwarten, dass die Inhalte skalierbar sind und an Komplexität und Wichtigkeit zunehmen.

Hier sind 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 Git herunterladen 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 festgelegt auf „Basic“ (im Gegensatz zu Projektbeteiligten).
  • Gehören einer Organisation und einem Projekt an.
  • Entsprechende Repositoryberechtigungen.
• 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. Dataflows) nachzuverfolgen und zu verwalten.

Ein wichtiger Nutzen der Verwendung der Quellcodeverwaltung mit Azure Repos ist eine verbesserte Zusammenarbeit zwischen Inhaltserstellern und die bessere Anpassung und Überwachung von Inhaltsänderungen und der Bereitstellung.

Das folgende Diagramm zeigt eine allgemeine Übersicht darüber, wie Azure DevOps die Zusammenarbeit mit Quellcodeverwaltung ermöglicht.

Das Diagramm veranschaulicht 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. Der neue Branch wird häufig als Feature-Branch bezeichnet, da er 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.

Verwenden von Verzweigungen

Inhaltsersteller erreichen die Zusammenarbeit mithilfe einer Branchingstrategie. Eine Verzweigungsstrategie ermöglicht es einzelnen Inhaltserstellenden, 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 an der lokalen Lösung ausgeführten Arbeiten werden mit einer beschreibenden Commitnachricht in eine Version des Branches im Remoterepository committet und gepusht. Eine Commitnachricht beschreibt die Änderungen, die in diesem Commit vorgenommen wurden.

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

• Welche Inhaltsersteller in einem Branch sollten für ihre eigene Arbeit klonen. Wenn diese Branches beispielsweise ein Klon des Hauptbranches sind (als Trunk-basierte Entwicklung bezeichnet), oder wenn es sich um andere Branches handelt, z. B. Releasebranches für bestimmte, geplante Versionen von Inhalten.
• Ob Sie bestimmte Aufgaben auf unterschiedliche Inhaltsreleases beschränken, indem Sie Releasebranches verwenden.
• Welche Branches bei Verwendung der Fabric Git-Integration eine Verbindung zu welchem Arbeitsbereich herstellen.

Batchänderungen in Commits

Während der Entwicklung von Inhalten sollten Ersteller regelmäßig Änderungen in Batches (oder Gruppen) stagen. Diese Änderungen sollten sich auf ein bestimmtes Arbeitselement der Lösung beziehen (z. B. ein Feature oder Problem). Wenn sie bereit sind, übernehmen Inhaltsersteller diese gestageten Änderungen.

Diese Art der Batchverarbeitung von Änderungen hat mehreren Nutzen.

• Es hilft bei der Strukturierung der Entwicklung 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 die Verknüpfung von Features und Problemen und schafft Transparenz über den Fortgang der Arbeiten.
• Technische Besitzer können Pull Request von Inhaltserstellern einfacher überprüfen, wenn Änderungen entsprechend als Batch bereitgestellt werden und klare Commit-Nachrichten haben.

Berücksichtigen Sie beim Stagen und Committen von Änderungen an Power BI-Inhalten die folgenden Faktoren.

• Ganz gleich, ob Sie Änderungen aus einem lokalen Repository oder aus 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 wird das Identifizieren und Gruppieren von Änderungen erleichtern, die Sie vornehmen.
• Ignorieren Sie harmlose oder nicht hilfreiche Metadatenänderungen mithilfe einer GITIGNORE-Datei oder einer GITATTRIBUTES-Datei. Dadurch wird sichergestellt, dass alle Änderungen, die Sie committen, aussagekräftig sind.

Erstellen von Pull Request 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 Pull Request zum Zusammenführen von Änderungen an Power BI-Inhalten verwenden, berücksichtigen Sie die folgenden Faktoren.

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

Prüfliste – Bei der Planung des Speicherortes von Dateien sind folgende Entscheidungen und Maßnahmen wichtig:

Zugehöriger Inhalt

Im nächsten Artikel dieser Reihe erfahren Sie, wie Sie Inhalte als Teil der Verwaltung des Inhaltslebenszyklus prüfen.