Power BI-Nutzungsszenarios: Enterprise-Inhaltsveröffentlichung

Hinweis

Dieser Artikel ist Teil der Artikelreihe zur Power BI-Implementierungsplanung. Diese Reihe konzentriert sich hauptsächlich auf den Power BI-Workload innerhalb von Microsoft Fabric. Eine Einführung in die Artikelreihe finden Sie unter Power BI-Implementierungsplanung.

Wenn Inhaltserstellende zusammenarbeiten, um Analyselösungen zu liefern, die für die Organisation wichtig sind, müssen sie eine zeitnahe und zuverlässige Lieferung von Inhalten an Benutzer sicherstellen. Technische Teams lösen diese Herausforderung mithilfe eines Prozesses namens DevOps. DevOps ermöglicht es Teams, Prozesse zu automatisieren und zu skalieren, indem Sie Methoden einführen, die die Bereitstellung verbessern und beschleunigen.

Hinweis

Datenteams, die vor den gleichen Herausforderungen stehen, können DataOps einsetzen. DataOps baut auf DevOps-Prinzipien auf, aber DataOps enthält zusätzliche spezifische Methoden für die Datenverwaltung, z. B. Datenqualitätssicherung und Governance. Wir beziehen uns in diesem Artikel auf DevOps, aber beachten Sie, dass die zugrunde liegenden Prinzipien auch für DataOps gelten können.

Inhaltserstellende und -benutzer profitieren von mehreren Vorteilen, wenn Sie DevOps-Methoden zum Veröffentlichen von Power BI-Inhalten einführen. Die folgenden Punkte enthalten eine allgemeine Übersicht über die Funktionsweise dieses Prozesses.

1. Entwickeln von Inhalten und Commits für ein Remote-Repository: Ersteller von Inhalten entwickeln ihre Lösung auf ihrem eigenen Computer. Sie committen und speichern ihre Arbeit in regelmäßigen Abständen während der Entwicklung in einem Remote-Repository. Ein Remote-Repository enthält die neueste Version der Lösung, auf die das gesamte Entwicklungsteam zugreifen kann.
2. Zusammenarbeiten und Verwalten von Inhaltsänderungen mithilfe der Versionskontrolle: Andere Inhaltserstellende können Revisionen an der Lösung vornehmen, indem sie einen Branch erstellen. Ein Branch ist eine Kopie eines Remote-Repository. Wenn diese Revisionen bereit und genehmigt sind, wird der Branch mit der neuesten Version der Lösung zusammengeführt. Alle Revisionen der Lösung werden nachverfolgt. Dieser Prozess wird als Versionskontrolle (oder Quellcodeverwaltung) bezeichnet.
3. Bereitstellen und Höherstufen von Inhalten mithilfe von Pipelines: Im Verwendungsszenarion Self-Service-Inhaltsveröffentlichung werden Inhalte mithilfe von Power BI-Bereitstellungspipelines über Entwicklungs-, Test- und Produktionsarbeitsbereiche heraufgestuft (oder bereitgestellt). Power BI-Bereitstellungspipelines können Inhalte manuell über die Benutzeroberfläche oder programmgesteuert mithilfe der REST-APIs in Power BI Premium-Arbeitsbereiche heraufstufen. Im Gegensatz dazu fördert die Veröffentlichung von Unternehmensinhalten (der Schwerpunkt dieses Nutzungsszenarios) Inhalte mithilfe von Azure Pipelines. Azure Pipelines ist ein Azure DevOps-Dienst, der das Testen, Verwalten und Bereitstellen von Inhalten mithilfe einer Reihe von angepassten programmgesteuerten Schritten automatisiert. Im Nutzungsszenario für die Veröffentlichung von Unternehmensinhalten können diese Pipelines auch als Continuous Integration und Continuous Delivery Pipelines (oder CI/CD) bezeichnet werden. Diese Pipelines integrieren häufig und automatisch Änderungen und optimieren die Veröffentlichung von Inhalten.

DevOps unterstützt einen ausgereiften, systematischen Ansatz für Inhaltsverwaltung und Veröffentlichung. Es ermöglicht Inhaltserstellenden die Zusammenarbeit an Lösungen und sorgt für eine schnelle und zuverlässige Lieferung von Inhalten für Benutzer. Wenn Sie DevOps-Methoden befolgen, profitieren Sie von optimierten Workflows, weniger Fehlern und verbesserten Erfahrungen für Inhaltserstellende und Inhaltsbenutzer.

Sie richten DevOps-Methoden für Ihre Power BI-Lösung mithilfe von Azure DevOps ein und verwalten sie. In Unternehmensszenarien können Sie die Inhaltsveröffentlichung mit Azure DevOps und den Power BI-REST-APIs auf drei verschiedene Arten automatisieren.

• Power BI-REST-APIs mit Power BI-Bereitstellungspipelines: Sie können Inhalte in Entwicklungsarbeitsbereiche importieren und Bereitstellungspipelines verwenden, um Inhalte über Test- und Produktionsarbeitsbereiche zu liefern. Sie steuern weiterhin die Bereitstellung von Azure DevOps und verwenden die Power BI-REST-APIs, um Bereitstellungspipelines anstelle einzelner Inhaltselemente zu verwalten. Darüber hinaus verwenden Sie den XMLA-Endpunkt, um Datenmodellmetadaten anstelle einer Power BI Desktop-Datei (PBIX) mit Azure DevOps bereitzustellen. Mit diesen Metadaten können Sie Änderungen auf Objektebene mithilfe der Versionskontrolle nachverfolgen. Dieser Ansatz ist zwar robuster und einfacher zu verwalten, erfordert jedoch Premium-Lizenzierung und moderate Skripterstellung, um den Import und die Bereitstellung von Inhalten mit den Power BI-REST-APIs einzurichten. Verwenden Sie diesen Ansatz, wenn Sie die Verwaltung des Inhaltslebenszyklus mit Bereitstellungspipelines vereinfachen möchten und über eine Premium-Lizenz verfügen. Der XMLA-Endpunkt und die Power BI-Bereitstellungspipelines sind Premium-Features.
• Power BI-REST-APIs: Sie können Inhalte auch in Entwicklungs-, Test- und Produktionsarbeitsbereiche importieren, indem Sie Azure DevOps und nur die Power BI-REST-APIs verwenden. Dieser Ansatz erfordert keine Premium-Lizenzierung, ist aber mit einem hohen Aufwand für Skripte und die Einrichtung verbunden, da die Bereitstellung außerhalb von Power BI verwaltet wird. Verwenden Sie diesen Ansatz, wenn Sie Power BI-Inhalte zentral aus Azure DevOps bereitstellen möchten oder keine Premium-Lizenz besitzen. Einen visuellen Vergleich zwischen den ersten beiden Ansätzen finden Sie im Flussdiagramm zu den Ansätzen der Releasepipeline.
• Power BI-Automatisierungstools mit Power BI-Bereitstellungspipelines: Sie können die Azure DevOps-Erweiterung für Power BI-Automatisierungstools verwenden, um Bereitstellungspipelines anstelle der Power BI-REST-APIs zu verwalten. Dieser Ansatz ist eine Alternative zur ersten Option, die die Power BI-REST-APIs mit Power BI-Bereitstellungspipelines verwendet. Die Erweiterung für Power BI-Automatisierungstools ist ein Open Source Tool. Es hilft Ihnen, Inhalte aus Azure DevOps zu verwalten und zu veröffentlichen, ohne PowerShell-Skripts schreiben zu müssen. Verwenden Sie diesen Ansatz, wenn Sie Bereitstellungspipelines aus Azure DevOps mit minimalem Skriptaufwand verwalten möchten und über eine Premium-Kapazität verfügen.

Dieser Ansatz ist eine Alternative zur ersten Option, die die Power BI-REST-APIs mit Power BI-Bereitstellungspipelines verwendet. Es wird beschrieben, wie Sie Azure DevOps zum Einrichten von DevOps-Methoden verwenden können. Außerdem wird beschrieben, wie Sie Azure Repos für Ihre Remote-Repositorys verwenden und das Testen, Integrieren und Bereitstellen von Inhalten mit Azure Pipelines automatisieren können. Azure DevOps ist nicht die einzige Möglichkeit zum Einrichten der Veröffentlichung von Unternehmensinhalten, aber aufgrund der einfachen Integration in Power BI eine gute Wahl.

Hinweis

Bei diesem Verwendungsszenario handelt es sich um eines der Szenarios zur Inhaltsverwaltung und -bereitstellung. Einige Aspekte, die in den Szenarios für die inhaltsorientierte Zusammenarbeit und Übermittlung von Inhalten beschrieben sind, werden der Kürze halber in diesem Artikel nicht behandelt. Lesen Sie für vollständige Informationen zuerst diese Artikel.

Tipp

Microsoft Fabric bietet weitere Optionen für die Veröffentlichung von Unternehmensinhalten durch die Fabric Git-Integration. Mit der Git-Integration können Sie einen Fabric-Arbeitsbereich mit einem Branch in Ihrem Azure Repos-Remote-Repository verknüpfen. Inhalte, die in diesem Bereich gespeichert sind, werden automatisch mit dem Arbeitsbereich synchronisiert, so als wären diese Inhalte im Arbeitsbereich veröffentlicht worden. Umgekehrt können Ersteller*innen von Inhalten Änderungen aus dem Fabric-Arbeitsbereich in das Remoterepository übertragen und veröffentlichen.

Die Git-Integration kann die Zusammenarbeit und die Veröffentlichung von Inhalten vereinfachen, erfordert aber eine bessere Planung der Verwendung von Fabric Workspaces und der Branching-Strategie. Weitere Informationen darüber, wie Sie die Fabric Git-Integration einrichten und nutzen können, finden Sie unter Erste Schritte mit der Git-Integration oder Tutorial: Verwaltung des gesamten Lebenszyklus.

Szenariodiagramm

Das folgende Diagramm enthält eine allgemeine Übersicht der häufigsten Benutzeraktionen und Power BI-Komponenten, die Unternehmens-Inhaltsveröffentlichung unterstützen. Der Fokus liegt auf der Verwendung von Azure DevOps zum programmgesteuerten Verwalten und Veröffentlichen von Inhalten im großen Stil über Entwicklungs-, Test- und Produktionsarbeitsbereiche im Power BI-Dienst.

Tipp

Wir empfehlen Ihnen, das Szenariodiagramm herunterzuladen, wenn Sie es in Ihre Präsentation, Dokumentation oder Ihren Blogbeitrag einbinden oder als Wandposter ausdrucken möchten. Da es sich um eine skalierbare Vektorgrafik (SVG) handelt, können Sie das Bild ohne Qualitätsverlust vergrößern oder verkleinern.

Das Szenariodiagramm veranschaulicht die folgenden Benutzeraktionen, Prozesse und Features.

Element	Beschreibung
	Inhaltsersteller*innen von Inhalten entwickeln Datenmodelle mit Power BI Desktop oder Tabular Editor und Berichte mit Power BI Desktop. Inhaltserstellende speichern ihre Arbeit während der Entwicklung in einem lokalen Repository.
	Inhaltsersteller*innen können eine Remoterepository klonen, um eine lokale Kopie dieses Inhalts abzurufen.
	Einige Datenquellen erfordern möglicherweise ein lokales Daten-Gateway oder ein VNet-Gateway für die Datenaktualisierung, z. B. solche, die sich in einem privaten Organisationsnetzwerk befinden.
	Inhaltserstellende committen und pushen ihre Änderungen während der Entwicklung regelmäßig an eine Remote-Repository, indem sie einen Git-Client wie Visual Studio Code verwenden. In diesem Diagramm ist das Remoterepository Azure Repos.
	Andere Inhaltserstellende verwenden Azure Repos, um Änderungen mit der Versionskontrolle nachzuverfolgen. Sie arbeiten zusammen, indem sie Änderungen in separate Branches committen.
	Änderungen an Inhalten im Remote-Repository lösen Azure Pipelines aus. Eine Validierungspipeline ist die erste Pipeline, die ausgelöst wird. Die Validierungspipeline führt automatisierte Tests durch, um Inhalte zu überprüfen, bevor sie veröffentlicht werden.
	Inhalt, der die Überprüfungspipeline besteht, löst eine nachfolgende Buildpipeline aus. Die Buildpipeline bereitet Inhalte für die Veröffentlichung im Power BI-Dienst vor. Bis zu diesem Punkt wird der Prozess in der Regel als Continuous Integration (CI) bezeichnet.
	Inhalte werden mithilfe von Releasepipelines veröffentlicht und bereitgestellt. Die Releasepipelines verwenden entweder die Power BI-REST-APIs oder den XMLA-Endpunkt des Arbeitsbereichs, um Inhalte programmgesteuert in den Power BI-Dienst zu importieren. Die Bereitstellung mithilfe von Releasepipelines wird in der Regel als Continuous Deployment (CD) bezeichnet.
	Ein Releasemanager steuert die Bereitstellung von Test- und Produktionsarbeitsbereichen mithilfe einer Azure Pipelines-Releasegenehmigung. Bei der Veröffentlichung von Unternehmensinhalten plant und koordiniert ein Releasemanager in der Regel die Inhaltsfreigabe für Test- und Produktionsumgebungen. Sie koordinieren und kommunizieren mit Inhaltserstellenden, Projektbeteiligten und Benutzern.
	Eine Releasepipeline veröffentlicht Inhalte im Entwicklungsarbeitsbereich oder transferiert Inhalte von Entwicklungs- zu Testarbeitsbereichen oder von Test- zu Produktionsarbeitsbereichen.
	Inhaltsersteller*innen, die in einem Arbeitsbereich arbeiten, der über den Fabric Kapazitätslizenzmodus verfügt, können die Git-Integration nutzen. Mit der Git-Integration können Inhaltsersteller*innen während der Entwicklung in einem privaten Arbeitsbereich arbeiten. Inhaltsersteller*innen synchronisieren einen Remote-Branch (in der Regel einen bestimmten Feature-Branch oder einen Bug-Branch) von Azure Repos mit ihrem privaten Arbeitsbereich. Inhaltsänderungen werden zwischen dem Remote-Branch in Azure Repos und dem Arbeitsbereich synchronisiert. In diesem Szenario müssen Inhaltsersteller*innen keine Azure Pipelines verwenden, um Inhalte zu veröffentlichen. Inhaltsersteller*innen können nach der Veröffentlichung auch regelmäßig Änderungen aus dem Arbeitsbereich committen und pushen. Wenn sie fertig sind, können Inhaltsersteller*innen einen Pull Request (PR) erstellen, um ihre Änderungen mit dem Haupt-Branch zusammenzuführen.
	Wenn Sie die Git-Integration verwenden, wird der Entwicklungsarbeitsbereich mit dem Haupt-Branch synchronisiert, um die neuesten Versionen der Inhalte zu erhalten. Dieser Inhalt umfasst alle Änderungen aus Pull Requests, die ein*e Release Manager*in überprüft, genehmigt und zusammenführt.
	Arbeitsbereiche sind auf Fabric-Kapazität-, Premium-Kapazität-, Premium pro Benutzer*in- oder Eingebettet-Lizenzmodus eingestellt, um die Verwendung von Power BI-Bereitstellungspipelines und des XMLA-Lese-/Schreibendpunkts zu ermöglichen.
	Ein*e Administrator*in der Bereitstellungspipeline richtet die Power BI-Bereitstellungspipeline mit drei Stufen ein: Entwicklung, Test und Produktion. Dabei ist jede Phase einem bestimmten Arbeitsbereich im Power BI-Dienst zugeordnet. Die Bereitstellungseinstellungen und der Zugriff werden für die Bereitstellungspipeline festgelegt.
	Der Entwicklungsarbeitsbereich enthält die neuesten Versionen der Inhalte einschließlich aller genehmigten und zusammengeführten Änderungen. Sobald die Freigabe erfolgt ist, werden die Inhalte über eine Releasepipeline aus dem Entwicklungs- in den Testarbeitsbereich übertragen.
	Prüfer*innen im Testarbeitsbereich führen Tests und Qualitätssicherungen an Inhalten durch. Sobald die Freigabe erfolgt ist, werden die Inhalte über eine Releasepipeline vom Test- in den Produktionsarbeitsbereich übertragen. Wenn Sie die Git-Integration mit Bereitstellungspipelines verwenden, wird der Testarbeitsbereich mit keinem Branch synchronisiert.
	Nachdem die Bereitstellungspipeline die Bereitstellung abgeschlossen hat, führen die Inhaltsersteller*innen die Aktivitäten nach der Bereitstellung manuell durch. Dazu gehören unter anderem das Einrichten einer geplanten Datenaktualisierung oder das Aktualisieren einer Power BI-App für den Produktionsarbeitsbereich. Wenn Sie die Git-Integration mit Bereitstellungspipelines verwenden, wird der Produktionsarbeitsbereich mit keinem Branch synchronisiert.
	Inhaltsbetrachter*innen greifen über den Produktionsarbeitsbereich oder eine Power BI-App auf den Inhalt zu.

Tipp

Es wird empfohlen, auch die Verwendungsszenarios für die Self-Service-Inhaltsveröffentlichung und erweiterte Datenmodellverwaltung zu überprüfen. Das Verwendungsszenario für die Veröffentlichung von Unternehmensinhalten basiert auf Konzepten, die in diesen Szenarios eingeführt werden.

Wesentliche Punkte

Nachstehend sind einige wichtige Punkte aufgeführt, auf die im Szenario für Self-Service-Inhaltsveröffentlichung besonders hingewiesen werden muss.

Versionskontrolle

Das Nachverfolgen von Änderungen während des Inhaltslebenszyklus ist wichtig, um eine stabile und konsistente Übermittlung von Inhalten an Benutzer sicherzustellen. In diesem Verwendungsszenario verwalten Ersteller und Besitzer von Inhalten Inhaltsänderungen in einem Remote-Repository mithilfe der Versionskontrolle. Die Versionskontrolle ist die Methode zum Verwalten von Änderungen an Dateien oder Code in einem zentralen Repository. Sie ermöglicht eine bessere Zusammenarbeit und effektive Verwaltung des Versionsverlaufs. Die Versionskontrolle bietet Vorteile für Inhaltserstellende, einschließlich der Möglichkeit, Änderungen zurückzusetzen oder zusammenzuführen.

Inhaltsersteller entwickeln in der Regel Datenmodelle im Tabular Editor, um eine bessere Versionskontrolle zu unterstützen. Im Gegensatz zu einem in Power BI Desktop entwickelten Datenmodell wird ein im Tabular Editor entwickeltes Datenmodell im lesbaren Metadatenformat gespeichert. Dieses Format ermöglicht die Versionskontrolle auf Objektebene des Datenmodells. Sie sollten die Versionskontrolle auf Objektebene verwenden, wenn Sie mit mehreren Personen am selben Datenmodell zusammenarbeiten. Weitere Informationen finden Sie im Verwendungsszenario Erweiterte Datenmodellverwaltung. Es ist nicht möglich, Änderungen anzuzeigen, die Sie in einer Power BI Desktop-Datei (PBIX) vorgenommen haben, z. B. die Berichtsdefinition oder das Datenmodell. Beispielsweise können Sie Änderungen an einer Berichtsseite nicht nachverfolgen, z. B. die verwendeten Grafikelemente, ihre Positionen und ihre Feldzuordnungen oder Formatierungen.

Inhaltserstellende speichern Datenmodellmetadatendateien und PBIX-Dateien in einem zentralen Remote-Repository, z. B. Azure Repos. 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 anspruchsvolle Optionen zum Nachverfolgen und Verwalten von Änderungen. Dieser Ansatz unterscheidet sich von dem Ansatz, der im Verwendungsszenario Self-Service-Inhaltsveröffentlichung beschrieben wird, bei dem der Ersteller OneDrive-Speicher mit Versionsnachverfolgung verwendet. Die Pflege eines sorgfältig kuratierten, dokumentierten Repositorys ist von entscheidender Bedeutung, da es die Grundlage aller Inhalte und der Zusammenarbeit ist.

Hier sind einige wichtige Überlegungen, die Ihnen beim Einrichten eines Remote-Repository für die Versionskontrolle helfen.

• Bereich: Definieren Sie den Bereich des Repositorys eindeutig. Im Idealfall ist der Bereich des Repositorys identisch mit dem Bereich der nachgelagerten Arbeitsbereiche und Apps, die Sie zum Bereitstellen von Inhalten an Besitzer verwenden.
• Zugriff: Sie sollten den Zugriff auf das Repository mithilfe eines ähnlichen Berechtigungsmodells einrichten, wie Sie es für Ihre Berechtigungen der Bereitstellungspipeline und Arbeitsbereichsrollen eingerichtet haben. Inhaltserstellende benötigen Zugriff auf das Repository.
• Dokumentation: Fügen Sie dem Repository Textdateien hinzu, um den Zweck, den Besitz, den Zugriff und die definierten Prozesse zu dokumentieren. In der Dokumentation kann z. B. beschrieben werden, wie Änderungen inszeniert und committet werden sollen.
• Tools: Zum Commiten und Pushen von Änderungen an ein Remote-Repository benötigen Inhaltserstellende einen Git-Client wie Visual Studio oder Visual Studio Code. Git ist ein verteiltes Versionskontrollsystem, das Änderungen in Ihren Dateien nachverfolgt. Informationen zu Git-Grundlagen finden Sie unter Was ist Git?.

Hinweis

Erwägen Sie die Verwendung von Git Large File Storage (LFS), wenn Sie Power BI Desktop Dateien (PBIX) committen möchten. Git LFS bietet erweiterte Optionen zum Verwalten von Dateien, bei denen Änderungen nicht sichtbar sind (nicht erkennbare Dateien), z. B. eine PBIX-Datei. Sie können beispielsweise Dateisperren verwenden, um gleichzeitige Änderungen an einem Power BI-Bericht während der Entwicklung zu verhindern. Git LFS verfügt jedoch über einen eigenen Client und eine eigene Konfiguration.

Zusammenarbeit mit Azure DevOps

Wenn eine Lösung an Umfang und Komplexität zunimmt, kann es erforderlich werden, dass mehrere Inhaltserstellende und -besitzer zusammenarbeiten. Mithilfe von Azure DevOps können Inhaltserstellende und -besitzer in einem zentralen, organisierten Hub kommunizieren und zusammenarbeiten.

Für die Zusammenarbeit und Kommunikation in Azure DevOps verwenden Sie unterstützende Dienste.

• Azure Boards: Inhaltsbesitzer verwenden Boards, um Arbeitselemente nachzuverfolgen. Arbeitselemente werden jeweils einem einzelnen Entwickler im Team zugewiesen und beschreiben Probleme, Fehler oder Features in der Lösung sowie die entsprechenden Projektbeteiligten.
• Azure Wiki: Inhaltserstellende teilen Informationen mit ihrem Team, um die Lösung zu verstehen und zur Lösung beizutragen.
• Azure Repos: Inhaltserstellende verfolgen Änderungen im Remote-Repository nach und führen sie in einer einzigen Lösung zusammen.
• Azure Pipelines: Pipelinebesitzer richten programmgesteuerte Logik ein, um die Lösung entweder automatisch oder bei Bedarf bereitzustellen.

Diagramm für den Zusammenarbeitsablauf

Das folgende Diagramm zeigt eine allgemeine Übersicht eines Beispiels, wie Azure DevOps die Zusammenarbeit im Verwendungsszenario für die Veröffentlichung von Unternehmensinhalten ermöglicht. Der Schwerpunkt dieses Diagramms liegt auf der Verwendung von Azure DevOps zum Erstellen eines strukturierten und dokumentierten Inhaltsveröffentlichungsprozesses.

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. Er koordiniert und kommuniziert 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.

Genauer gesagt, erreichen Inhaltserstellende die Zusammenarbeit mithilfe einer Verzweigungsstrategie. Bei einer Branching-Strategie geht es darum, wie Inhaltsersteller*innen Branches erstellen, verwenden und zusammenführen, um Änderungen an Inhalten effektiv durchzuführen und zu verwalten. Einzelne Inhaltsersteller*innen arbeiten isoliert in ihrem lokalen Repository. 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 Commitnachricht in eine Version des Branches im Remote-Repository commitet und gepusht. Eine Commitnachricht beschreibt die Änderungen, die in diesem Commit vorgenommen wurden.

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.

Empfehlungen für die Zusammenarbeit

Es wird empfohlen, einen strukturierten Prozess für die Zusammenarbeit von Inhaltserstellenden zu definieren. Stellen Sie sicher, dass Sie Folgendes festlegen:

• Wie der Arbeitsbereich ausgelegt ist und wie Branches erstellt, benannt und verwendet werden.
• Wie Autoren Änderungen gruppieren und sie mit Commitnachrichten beschreiben.
• Wer für die Überprüfung und Genehmigung von Pull Requests verantwortlich ist.
• Wie Zusammenführungskonflikte gelöst werden.
• Wie Änderungen, die in verschiedenen Branches vorgenommen werden, in einem einzelnen Branch zusammengeführt werden.
• Wie Inhalte getestet werden und wer Tests durchführt, bevor Inhalte bereitgestellt werden.
• Wie und wann Änderungen in Entwicklungs-, Test- und Produktionsarbeitsbereichen bereitgestellt werden.
• Wie und wann bereitgestellte Änderungen oder Versionen der Lösung zurückgesetzt werden sollten.

Wichtig

Der von DevOps bereitgestellte Wert ist direkt proportional zur Einhaltung der Prozesse, die die Verwendung definieren.

Eine erfolgreiche Zusammenarbeit hängt von einem klar definierten Prozess ab. Daher ist es wichtig, den End-to-End-Entwicklungsworkflow klar zu beschreiben und zu dokumentieren. Stellen Sie sicher, dass die ausgewählten Strategien und Prozesse mit den vorhandenen Methoden in Ihrem Team übereinstimmen, und wenn nicht, wie Änderungen verwaltet werden. Stellen Sie außerdem sicher, dass die Prozesse klar sind und allen Teammitgliedern und Projektbeteiligten kommuniziert werden. Stellen Sie sicher, dass Teammitglieder und Projektbeteiligte, die mit den Prozessen noch nicht vertraut sind, in der Einführung geschult werden, und dass sie den Wert einer erfolgreichen DevOps-Einführung zu schätzen wissen.

Power BI-REST-APIs

Sie entwickeln programmgesteuerte Logik zum Importieren und Bereitstellen von Inhalten aus Azure DevOps mithilfe der Power BI-REST-APIs. Sie importieren Power BI-Dateien (PBIX) mithilfe eines Importvorgangs in einen Arbeitsbereich. Sie verwenden einen Pipelinevorgang, um einige Inhalte oder alle Inhalte mithilfe von Power BI-Bereitstellungspipelines für Test- oder Produktionsarbeitsbereiche bereitzustellen. Die programmgesteuerte Logik wird in Azure Pipelines definiert.

Es wird empfohlen, einen Dienstprinzipal zu verwenden, um Power BI-REST-APIs in Ihren Pipelines aufzurufen. Ein Dienstprinzipal ist für unbeaufsichtigte, automatisierte Aktivitäten vorgesehen und basiert nicht auf Benutzeranmeldeinformationen. Einige Elemente und Aktivitäten werden jedoch nicht von den Power BI-REST-APIs oder bei Verwendung eines Dienstprinzipals wie Dataflows unterstützt.

Wenn Sie einen Dienstprinzipal verwenden, achten Sie darauf, Berechtigungen sorgfältig zu verwalten. Ihr Ziel sollte es sein, das Prinzip der geringsten Rechte zu befolgen. Sie sollten ausreichende Berechtigungen für den Dienstprinzipal ohne die Überbereitstellung von Berechtigungen festlegen. Verwenden Sie Azure Key Vault oder einen anderen Dienst, der die Geheimnisse und Anmeldeinformationen des Dienstprinzipals sicher speichert.

Achtung

Wenn Sie über ein Datenmodell verfügen, das als lesbares Metadatenformat gespeichert ist, kann es nicht mithilfe der Power BI-REST-APIs veröffentlicht werden. Stattdessen müssen Sie es mithilfe des XMLA-Endpunkts veröffentlichen. Sie können Metadatendateien mit Tools von Drittanbietern wie der Tabular Editor-Befehlszeilenschnittstelle (CLI) veröffentlichen. Sie können Metadatendateien auch programmgesteuert veröffentlichen, indem Sie Ihre eigene benutzerdefinierte .NET-Entwicklung verwenden. Das Entwickeln einer benutzerdefinierten Lösung erfordert mehr Aufwand, da Sie die Microsoft Tabular Object Model (TOM)-Erweiterung der AMO-Clientbibliotheken (Analysis Management Object) verwenden müssen.

Azure Pipelines

Azure Pipelines automatisiert programmgesteuert Tests, Verwaltung und Bereitstellung von Inhalten. Beim Ausführen einer Pipeline werden die Schritte in der Pipeline automatisch ausgeführt. Pipelinebesitzer können die Auslöser, Schritte und Funktionen anpassen, um die Bereitstellungsanforderungen zu erfüllen. Daher variieren die Anzahl und die Arten von Pipelines abhängig von den Lösungsanforderungen. Beispielsweise kann eine Azure Pipeline vor einer Bereitstellung automatisierte Tests ausführen oder Datenmodellparameter ändern.

Es gibt drei Arten von Azure Pipelines, die Sie zum Testen, Verwalten und Bereitstellen Ihrer Power BI-Lösung einrichten können:

• Validierungspipelines.
• Buildpipelines.
• Releasepipelines

Hinweis

Ihre Veröffentlichungslösung muss nicht alle drei Pipelines enthalten. Abhängig von Ihrem Workflow und Ihren Anforderungen können Sie eine oder mehrere der in diesem Artikel beschriebenen Varianten der Pipelines einrichten, um die Veröffentlichung von Inhalten zu automatisieren. Diese Möglichkeit zum Anpassen der Pipelines ist ein Vorteil von Azure Pipelines gegenüber den integrierten Power BI-Bereitstellungspipelines. Wenn Sie beispielsweise keine Validierungspipeline benötigen, können Sie auch nur Build- und Releasepipelines verwenden.

Validierungspipelines

Validierungspipelines führen grundlegende Qualitätsprüfungen von Datenmodellen durch, bevor sie in einem Entwicklungsarbeitsbereich veröffentlicht werden. In der Regel lösen Änderungen in einem Branch des Remote-Repositorys die Pipeline aus, um diese Änderungen mit automatisierten Tests zu überprüfen.

Beispiele für automatisierte Tests sind das Überprüfen des Datenmodells auf Regelverstöße mit Best Practice Analyzer (BPA) oder das Ausführen von DAX-Abfragen für ein veröffentlichtes Semantikmodell. Die Ergebnisse dieser Tests werden dann zu Dokumentations- und Überwachungszwecken im Remote-Repository gespeichert. Datenmodelle, bei denen die Überprüfung fehlschlägt, sollten nicht veröffentlicht werden. Stattdessen sollte die Pipeline Inhaltserstellende über die Probleme benachrichtigen.

Buildpipelines

Buildpipelines bereiten Datenmodelle für die Veröffentlichung im Power BI-Dienst vor. Diese Pipelines kombinieren serialisierte Modellmetadaten in einer einzelnen Datei, die später von einer Releasepipeline veröffentlicht werden (im Diagramm zu Releasepipelines beschrieben). Eine Buildpipeline kann auch andere Änderungen an den Metadaten vornehmen, z. B. das Ändern von Parameterwerten. Die Buildpipelines erzeugen Bereitstellungsartefakte, die aus Datenmodellmetadaten (für Datenmodelle) und Power BI Desktop-Dateien (PBIX) bestehen, die für die Veröffentlichung im Power BI-Dienst bereit sind.

Releasepipelines

Releasepipelines veröffentlichen Inhalte oder stellen sie bereit. Eine Veröffentlichungslösung umfasst in der Regel mehrere Releasepipelines, abhängig von der Zielumgebung.

• Releasepipeline für Entwicklung: Diese erste Pipeline wird automatisch ausgelöst. Sie veröffentlicht Inhalte in einem Entwicklungsarbeitsbereich, nachdem die Build- und Validierungspipelines erfolgreich waren.
• Releasepipelines für Test und Produktion: Diese Pipelines werden nicht automatisch ausgelöst. Stattdessen werden sie bei Bedarf oder nach Genehmigung ausgelöst. Releasepipelines für Test und Produktion stellen Inhalte nach der Freigabegenehmigung in einem Test- oder Produktionsarbeitsbereich bereit. Releasegenehmigungen stellen sicher, dass Inhalte nicht automatisch in einer Test- oder Produktionsphase bereitgestellt werden, bevor sie bereit sind. Diese Genehmigungen werden von Releasemanagern bereitgestellt, die für die Planung und Koordinierung der Inhaltsfreigabe in Test- und Produktionsumgebungen verantwortlich sind.

Es gibt zwei verschiedene Ansätze zum Veröffentlichen von Inhalten mit Test- und Releasepipelines. Sie stufen Inhalte entweder mithilfe einer Power BI-Bereitstellungspipeline hoch oder veröffentlichen Inhalte im Power BI-Dienst aus Azure DevOps.

Das folgende Diagramm zeigt den ersten Ansatz. Bei diesem Ansatz orchestrieren Releasepipelines die Inhaltsbereitstellung für Test- und Produktionsarbeitsbereiche mithilfe von Power BI-Bereitstellungspipelines. Inhalte werden durch Entwicklungs-, Test- und Produktionsarbeitsbereiche in Power BI höher gestuft. Dieser Ansatz ist zwar robuster und einfacher zu verwalten, erfordert jedoch eine Premium-Lizenzierung.

Das Diagramm veranschaulicht die folgenden Benutzeraktionen, Prozesse und Features des ersten Ansatzes.

Element	Beschreibung
	Im ersten Ansatz veröffentlichen die Releasepipelines Inhalte mithilfe des XMLA-Endpunkts und der Power BI-REST-APIs mit Power BI-Bereitstellungspipelines. Inhalte werden veröffentlicht und dann durch Entwicklungs-, Test- und Produktionsarbeitsbereiche höher gestuft. Power BI-Bereitstellungspipelines und der XMLA-Lese-/Schreibendpunkt sind Premium-Features.
	Eine erfolgreiche Branchzusammenführung oder der Abschluss einer Upstream-Pipeline löst die Buildpipeline aus. Die Buildpipeline bereitet dann Inhalte für die Veröffentlichung vor und löst die Entwicklungreleasepipeline aus.
	Die Entwicklungreleasepipeline veröffentlicht Inhalte im Entwicklungsarbeitsbereich mithilfe des XMLA-Endpunkts (für Datenmodellmetadaten) oder der Power BI-REST-APIs (für Power BI Desktop Dateien, die Datenmodelle und Berichte enthalten können). Die Entwicklungspipeline verwendet die Befehlszeilenschnittstelle (CLI) des Tabular Editors, um Datenmodellmetadaten mithilfe des XMLA-Endpunkts bereitzustellen.
	Eine Releasegenehmigung oder ein bedarfsabhängiger Auslöser aktiviert die Testreleasepipeline.
	Die Testreleasepipeline stellt Inhalte mithilfe der Power BI-REST-API-Bereitstellungsvorgänge bereit, die die Power BI-Bereitstellungspipeline ausführen.
	Die Power BI-Bereitstellungspipeline stuft Inhalte aus dem Entwicklungsarbeitsbereich in den Testarbeitsbereich hoch. Nach der Bereitstellung führt die Releasepipeline Aktivitäten mithilfe der Power BI-REST-APIs aus (nicht im Diagramm dargestellt).
	Eine Releasegenehmigung oder ein bedarfsabhängiger Auslöser aktiviert die Produktionsreleasepipeline.
	Die Produktionsreleasepipeline stellt Inhalte mithilfe der Power BI-REST-API-Bereitstellungsvorgänge bereit, die die Power BI-Bereitstellungspipeline ausführen.
	Die Power BI-Bereitstellungspipeline stuft Inhalte aus dem Testarbeitsbereich in den Produktionsarbeitsbereich hoch. Nach der Bereitstellung führt die Releasepipeline Aktivitäten mithilfe der Power BI-REST-APIs aus (nicht im Diagramm dargestellt).

Das folgende Diagramm zeigt den zweiten Ansatz. Bei diesem Ansatz werden keine Bereitstellungspipelines verwendet. Stattdessen werden Releasepipelines verwendet, um Inhalte in Test- und Produktionsarbeitsbereichen aus Azure DevOps zu veröffentlichen. Insbesondere erfordert dieser zweite Ansatz keine Premium-Lizenzierung, wenn Sie nur Power BI Desktop-Dateien mit den Power BI-REST-APIs veröffentlichen. Es ist jedoch mit mehr Aufwand und Komplexität bei der Einrichtung verbunden, da Sie die Bereitstellung außerhalb von Power BI verwalten müssen. Entwicklungsteams, die bereits DevOps für Datenlösungen außerhalb von Power BI verwenden, sind mit diesem Ansatz möglicherweise besser vertraut. Entwicklungsteams, die diesen Ansatz verwenden, können die Bereitstellung von Datenlösungen in Azure DevOps konsolidieren.

Das Diagramm veranschaulicht die folgenden Benutzeraktionen, Prozesse und Features des zweiten Ansatzes.

Element	Beschreibung
	Beim zweiten Ansatz veröffentlichen die Releasepipelines Inhalte nur mithilfe des XMLA-Endpunkts und der Power BI-REST-APIs. Inhalte werden in Entwicklungs-, Test- und Produktionsarbeitsbereichen veröffentlicht.
	Eine erfolgreiche Branchzusammenführung oder der Abschluss einer Upstream-Pipeline löst die Buildpipeline aus. Die Buildpipeline bereitet dann Inhalte für die Veröffentlichung vor und löst die Entwicklungreleasepipeline aus.
	Die Entwicklungreleasepipeline veröffentlicht Inhalte im Entwicklungsarbeitsbereich mithilfe des XMLA-Endpunkts (für Datenmodellmetadaten) oder der Power BI-REST-APIs (für Power BI Desktop Dateien, die Datenmodelle und Berichte enthalten können). Die Entwicklungspipeline verwendet die Befehlszeilenschnittstelle (CLI) des Tabular Editors, um Datenmodellmetadaten mithilfe des XMLA-Endpunkts bereitzustellen.
	Eine Releasegenehmigung oder ein bedarfsabhängiger Auslöser aktiviert die Testreleasepipeline.
	Die Entwicklungreleasepipeline veröffentlicht Inhalte im Testarbeitsbereich mithilfe des XMLA-Endpunkts (für Datenmodellmetadaten) oder der Power BI-REST-APIs (für Power BI Desktop Dateien, die Datenmodelle und Berichte enthalten können). Die Entwicklungspipeline verwendet die Befehlszeilenschnittstelle (CLI) des Tabular Editors, um Datenmodellmetadaten mithilfe des XMLA-Endpunkts bereitzustellen. Nach der Bereitstellung führt die Releasepipeline Aktivitäten mithilfe der Power BI-REST-APIs aus (nicht im Diagramm dargestellt).
	Eine Releasegenehmigung oder ein bedarfsabhängiger Auslöser aktiviert die Produktionsreleasepipeline.
	Die Entwicklungreleasepipeline veröffentlicht Inhalte im Produktionsarbeitsbereich mithilfe des XMLA-Endpunkts (für Datenmodellmetadaten) oder der Power BI-REST-APIs (für Power BI Desktop Dateien, die Datenmodelle und Berichte enthalten können). Die Entwicklungspipeline verwendet die Befehlszeilenschnittstelle (CLI) des Tabular Editors, um Datenmodellmetadaten mithilfe des XMLA-Endpunkts bereitzustellen. Nach der Bereitstellung führt die Releasepipeline Aktivitäten mithilfe der Power BI-REST-APIs aus (nicht im Diagramm dargestellt).

Releasepipelines sollten Aktivitäten nach der Bereitstellung verwalten. Diese Aktivitäten können das Festlegen von Anmeldeinformationen für ein Semantikmodell oder das Aktualisieren der Power BI-App für Test- und Produktionsarbeitsbereiche umfassen. Es wird empfohlen, Benachrichtigungen einzurichten, um relevante Personen über Bereitstellungsaktivitäten zu informieren.

Tipp

Mithilfe eines Repositorys für die Versionskontrolle können Inhaltsersteller einen Rollbackprozess erstellen. Der Rollbackprozess kann die letzte Bereitstellung rückgängig machen, indem die vorherige Version wiederhergestellt wird. Erwägen Sie die Erstellung einer separaten Gruppe von Azure Pipelines, die Sie auslösen können, um Produktionsänderungen zurückzusetzen. Überlegen Sie sorgfältig, welche Prozesse und Genehmigungen erforderlich sind, um ein Rollback zu initiieren. Stellen Sie sicher, dass diese Prozesse dokumentiert werden.

Power BI-Bereitstellungspipelines

Eine Power BI-Bereitstellungspipeline besteht aus drei Phasen: Entwicklung, Test und Produktion. Sie weisen jeder Phase in der Bereitstellungspipeline einen einzelnen Power BI-Arbeitsbereich zu. Wenn eine Bereitstellung erfolgt, stuft die Bereitstellungspipeline Power BI-Elemente von einem Arbeitsbereich in einen anderen hoch.

Eine Azure Pipelines-Releasepipeline verwendet die Power BI-REST-APIs, um Inhalte mithilfe einer Power BI-Bereitstellungspipeline bereitzustellen. Zugriff auf den Arbeitsbereich und die Bereitstellungspipeline ist für Benutzer*innen erforderlich, die eine Bereitstellung durchführen. Es wird empfohlen, den Zugriff auf die Bereitstellungspipeline zu planen, damit Pipelinebenutzer den Bereitstellungsverlauf anzeigen und Inhalte vergleichen können.

Tipp

Wenn Sie Datenarbeitsbereiche von Berichtsarbeitsbereichen trennen, sollten Sie die Verwendung von Azure Pipelines in Betracht ziehen, um die Inhaltsveröffentlichung mit mehreren Power BI-Bereitstellungspipelines zu orchestrieren. Semantikmodelle werden zuerst bereitgestellt und dann aktualisiert. Zuletzt werden Berichte bereitgestellt. Dieser Ansatz hilft Ihnen, die Bereitstellung zu vereinfachen.

Premium-Lizenzierung

Power BI-Bereitstellungspipelines und der XMLA-Lese-/Schreibendpunkt sind Premium-Features. Diese Features sind mit Power BI Premium-Kapazität und Power BI Premium-Einzelbenutzer (PPU) verfügbar.

PPU ist eine kostengünstige Möglichkeit, die Veröffentlichung von Unternehmensinhalten für Entwicklungs- und Testarbeitsbereiche zu verwalten, die in der Regel nur wenige Benutzer haben. Dieser Ansatz hat den zusätzlichen Vorteil, dass Entwicklungs- und Testworkloads von Produktionsworkloads isoliert werden.

Hinweis

Sie können die Veröffentlichung von Unternehmensinhalten weiterhin ohne Premium-Lizenz einrichten, wie im zweiten Ansatz im Abschnitt Releasepipeline beschrieben. Im zweiten Ansatz verwenden Sie Azure Pipelines, um die Bereitstellung von Power BI Desktop-Dateien in Entwicklungs-, Test- und Produktionsarbeitsbereichen zu verwalten. Sie können jedoch keine Modellmetadaten mithilfe des XMLA-Endpunkts bereitstellen, da es nicht möglich ist, ein Semantikmodell im Metadatenformat mit den Power BI-REST-APIs zu veröffentlichen. Außerdem ist es nicht möglich, Inhalte über Umgebungen mit Bereitstellungspipelines ohne Premium-Lizenz höher zu stufen.

Gatewaysetup

Beim Zugriff auf Datenquellen, die sich im privaten Organisationsnetzwerk oder in einem virtuellen Netzwerk befinden, ist normalerweise ein Datengateway erforderlich. Ein Gateway erfüllt zwei Zwecke: Aktualisieren importierter Daten oder Anzeigen eines Berichts, der eine Liveverbindung oder ein DirectQuery-Semantikmodell abfragt (nicht im Szenariodiagramm dargestellt).

Beim Arbeiten in mehreren Umgebungen ist es üblich, Entwicklungs-, Test- und Produktionsverbindungen für unterschiedliche Quellsysteme einzurichten. Verwenden Sie in diesem Fall Datenquellenregeln und Parameterregeln, um Werte zu verwalten, die sich zwischen verschiedenen Umgebungen unterscheiden. Sie können Azure Pipelines verwenden, um Gateways mithilfe der Gatewayvorgänge der Power BI-REST-APIs zu verwalten.

Hinweis

Anstelle von Gateways im persönlichen Modus wird dringend ein zentrales Datengateway im Standardmodus empfohlen. Im Standardmodus unterstützt das Datengateway Liveverbindungs- und DirectQuery-Vorgänge (zusätzlich zu geplanten Datenaktualisierungsvorgängen).

Systemüberwachung

Das Aktivitätsprotokoll erfasst Benutzeraktivitäten, die im Power BI-Dienst stattfinden. Power BI-Administratoren können das Aktivitätsprotokoll verwenden, um Bereitstellungsaktivitäten zu überwachen.

Sie können die Power BI-Metadatenüberprüfungs-APIs verwenden, um einen Mandantenbestand zu erstellen. Die API-Ergebnisse sind hilfreich, um zu überprüfen, welche Elemente in den einzelnen Arbeitsbereichen bereitgestellt wurden, um die Herkunft zu und die Sicherheitseinstellungen zu überprüfen.

In Azure DevOps gibt es auch ein Überwachungsprotokoll, das sich außerhalb des Power BI-Diensts befindet. Azure DevOps-Administratoren können das Überwachungsprotokoll verwenden, um Aktivitäten in Remote-Repositorys und Pipelines zu überprüfen.

Zugehöriger Inhalt

Weitere nützliche Szenarios, die Ihnen bei Entscheidungen zur Power BI-Implementierung helfen können, finden Sie im Artikel Power BI-Verwendungsszenarios.