Bewährte Methoden für die Lebenszyklusverwaltung
Dieser Artikel bietet Anleitungen für Daten- und Analyseersteller, die ihre Inhalte während des gesamten Lebenszyklus in Microsoft Fabric verwalten. Der Artikel konzentriert sich auf die Verwendung der Git-Integration für die Quellcodeverwaltung und Bereitstellungspipelines als Releasetool. Eine allgemeine Anleitung zur Veröffentlichung von Unternehmensinhalten finden Sie unter Enterprise-Inhaltsveröffentlichung.
Wichtig
Dieses Feature befindet sich in der Vorschauphase.
Dieser Artikel ist in vier Abschnitte unterteilt:
Inhaltsvorbereitung: Bereiten Sie Ihre Inhalte auf die Lebenszyklusverwaltung vor.
Bereitstellung: Lernen Sie die besten Möglichkeiten zur Erstellung von Inhalten in der Entwicklungsphase für Bereitstellungspipelines kennen.
Test: Erfahren Sie, wie Sie die Testphase für Bereitstellungspipelines zum Testen Ihrer Umgebung verwenden können.
Produktion: Nutzen Sie die Produktionsphase für Bereitstellungspipelines, wenn Sie Ihre Inhalte für die Nutzung verfügbar machen.
Inhaltsvorbereitung
Um Ihre Inhalte optimal auf die durchgängige Verwaltung während des gesamten Lebenszyklus vorzubereiten, lesen Sie die Informationen in diesem Abschnitt, bevor Sie:
Freigeben von Inhalten für die Produktion.
Beginn der Verwendung einer Bereitstellungspipeline für einen bestimmten Arbeitsbereich.
Aufteilen der Entwicklung auf Teams
Verschiedene Teams im Unternehmen haben in der Regel unterschiedliche Fachkenntnisse, Verantwortlichkeiten und Arbeitsmethoden, selbst wenn sie am selben Projekt arbeiten. Es ist wichtig, Grenzen zu setzen und gleichzeitig jedem Team seine Unabhängigkeit zu lassen, damit alle Teammitglieder so arbeiten können, wie sie möchten. Sie könnten separate Arbeitsbereiche für verschiedene Teams einrichten. Mit separaten Arbeitsbereichen kann jedes Team über unterschiedliche Berechtigungen verfügen, mit unterschiedlichen Quellcodeverwaltungsrepositorys arbeiten und Inhalte in einem anderen Rhythmus an die Produktion übergeben. Die meisten Elemente können Daten arbeitsbereichsübergreifend verknüpfen und nutzen, sodass die Zusammenarbeit an denselben Daten und Projekten nicht beeinträchtigt wird.
Planen Ihres Berechtigungsmodells
Sowohl die Git-Integration als auch Bereitstellungspipelines erfordern andere Berechtigungen als nur die Arbeitsbereichsberechtigungen. Erfahren Sie mehr über die Berechtigungsanforderungen für die Git-Integration und Bereitstellungspipelines.
Um einen sicheren und einfachen Workflow zu implementieren, planen Sie, wer Zugriff auf die einzelnen Bereiche der verwendeten Umgebungen erhält, sowohl auf das Git-Repository als auch auf die Entwicklungs-/Test-/Produktionsphasen in einer Pipeline. Berücksichtigen Sie unter anderem Folgendes:
Wer sollte Zugriff auf den Quellcode im Git-Repository erhalten?
Welche Vorgänge sollten Benutzer mit Pipelinezugriff in jeder Phase ausführen dürfen?
Wer überprüft Inhalte in der Testphase?
Sollten Reviewer für die Testphase Zugriff auf die Pipeline erhalten?
Wer soll die Bereitstellung in der Produktionsphase betreuen?
Welchen Arbeitsbereich weisen Sie einer Pipeline zu oder verbinden Sie mit Git?
Mit welchem Branch verbinden Sie den Arbeitsbereich? Wie lautet die für diesen Branch definierte Richtlinie?
Wird der Arbeitsbereich von mehreren Teammitgliedern gemeinsam genutzt? Sollen Änderungen direkt im Arbeitsbereich oder nur über Pull Requests vorgenommen werden?
Welchen Phasen wird Ihr Arbeitsbereich zugewiesen?
Müssen Änderungen an den Berechtigungen des Arbeitsbereichs vorgenommen werden, den Sie zuweisen?
Verbinden verschiedener Phasen mit verschiedenen Datenbanken
Eine Produktionsdatenbank sollte immer stabil und verfügbar sein. Es sollte nicht mit Abfragen überlastet werden, die von BI-Ersteller*innen zu Entwicklungs- oder Testzwecken für ihre Semantikmodelle generiert wurden. Erstellen Sie getrennte Datenbanken für Entwicklungs- und Testzwecke, um die Produktionsdaten zu schützen und die Entwicklungsdatenbank nicht mit dem gesamten Volumen der Produktionsdaten zu überlasten.
Verwenden von Parametern für Konfigurationen, die sich zwischen den Phasen ändern
Fügen Sie jeder Definition, die sich zwischen den Entwicklungs-/Test-/Produktionsphasen ändern könnte, nach Möglichkeit Parameter hinzu. Mithilfe von Parametern können Sie die Definitionen einfach ändern, wenn Sie Ihre Änderungen in die Produktion übernehmen. Obwohl es immer noch keine einheitliche Möglichkeit zum Verwalten von Parametern in Fabric gibt, wird empfohlen, sie für Elemente zu verwenden, die jede Art von Parametrisierung unterstützen.
Parameter können zu verschiedenen Zwecken verwendet werden, z. B. zum Definieren von Verbindungen mit Datenquellen oder mit internen Elementen in Fabric. Sie können auch verwendet werden, um Änderungen an Abfragen, Filtern und den Texten vorzunehmen, die Benutzern angezeigt werden.
In Bereitstellungspipelines können Sie Parameterregeln konfigurieren, um unterschiedliche Werte für die einzelnen Bereitstellungsphasen festzulegen.
Entwicklung
In diesem Abschnitt finden Sie Anleitungen für die Arbeit mit den Bereitstellungspipelines und für die Verwendung von Git für Ihre Entwicklungsstufe.
Sichern Ihrer Arbeit in einem Git-Repository
Dank der Git-Integration kann jeder Entwickler seine Arbeit sichern, indem er sie in Git committet. Um Ihre Arbeit in Fabric ordnungsgemäß zu sichern, sind hier einige grundlegende Regeln zu beachten:
Stellen Sie sicher, dass Sie über eine isolierte Umgebung verfügen, damit andere Ihre Arbeit nicht überschreiben, bevor ein Commit ausgeführt wird. Dies bedeutet, dass Sie in einem Desktoptool (z. B. VSCode, Power BI Desktop usw.) oder in einem separaten Arbeitsbereich arbeiten, auf den keine anderen Benutzer*innen zugreifen können.
Führen Sie einen Commit in einem Branch aus, den Sie erstellt haben und den kein anderer Entwickler verwendet. Wenn Sie einen Arbeitsbereich als Erstellungsumgebung verwenden, informieren Sie sich über die Arbeit mit Branches.
Änderungen, die zusammen bereitgestellt werden müssen, sollten zusammen committet werden. Diese Empfehlung gilt für ein einzelnes oder mehrere Elemente, die sich auf dieselbe Änderung beziehen. Das gemeinsame Committen aller zusammengehörigen Änderungen kann Ihnen später bei der Bereitstellung in anderen Phasen, beim Erstellen von Pull Requests oder beim Zurücksetzen von Änderungen helfen.
Umfangreiche Commits können eine maximale Commitgröße erreichen. Achten Sie auf die Anzahl der Elemente, die Sie zusammen committen, oder auf die allgemeine Größe eines Elements. Beispielsweise können Berichte größer ausfallen, wenn umfangreiche Bilder hinzugefügt werden. Umfangreiche Elemente in Quellcodeverwaltungssystemen zu speichern, ist eine schlechte Praktik, auch wenn sie funktioniert. Überlegen Sie, wie Sie die Größe Ihrer Elemente verringern können, wenn diese viele statische Ressourcen wie Bilder enthalten.
Rollback der Änderungen
Nachdem Sie Ihre Arbeit gesichert haben, kann es sein, dass Sie zu einer früheren Version zurückkehren und diese im Arbeitsbereich wiederherstellen möchten. Es gibt einige Möglichkeiten zum Wiederherstellen einer früheren Version:
Schaltfläche „Rückgängig“: Der Vorgang Rückgängig ist eine einfache und schnelle Möglichkeit, die unmittelbar vorgenommenen Änderungen rückgängig zu machen, solange noch kein Commit ausgeführt wurde. Sie können auch jedes Element einzeln rückgängig machen. Erfahren Sie mehr über den Vorgang Rückgängig.
Zurücksetzen auf ältere Commits: Die Benutzeroberfläche bietet keine direkte Möglichkeit, zu einem vorherigen Commit zurückzukehren. Die beste Option besteht darin, einen älteren Commit mithilfe von git revert oder git reset auf HEAD höherzustufen. So ist erkennbar, dass im Bereich „Quellcodeverwaltung“ eine Änderung vorhanden ist, und Sie können den Arbeitsbereich mit diesem neuen Commit aktualisieren.
Da die Daten nicht in Git gespeichert werden, sollten Sie bedenken, dass das Zurücksetzen eines Datenelements auf eine ältere Version die vorhandenen Daten beeinträchtigen könnte, wodurch Sie die Daten möglicherweise löschen müssen oder der Vorgang fehlschlägt. Überprüfen Sie dies im Voraus, bevor Sie die Änderungen zurücksetzen.
Arbeiten mit einem privaten Arbeitsbereich
Wenn Sie isoliert arbeiten möchten, verwenden Sie einen separaten Arbeitsbereich als isolierte Umgebung. Weitere Informationen zum Isolieren Ihrer Arbeitsumgebung finden Sie unter Arbeiten mit Branches. Um einen optimalen Workflow für Sie und das Team zu schaffen, sollten Sie die folgenden Punkte berücksichtigen:
Einrichten des Arbeitsbereichs: Bevor Sie beginnen, stellen Sie sicher, dass Sie einen neuen Arbeitsbereich erstellen können (falls Sie noch keinen haben), dass Sie ihn einer Fabric-Kapazität zuweisen können und dass Sie Zugriff auf Daten haben, um in Ihrem Arbeitsbereich zu arbeiten.
Erstellen eines neuen Branches: Erstellen Sie einen neuen Branch aus dem Mainbranch, damit Ihre Inhalte auf dem neuesten Stand sind. Stellen Sie außerdem sicher, dass Sie eine Verbindung mit dem richtigen Ordner im Branch herstellen, damit Sie die richtigen Inhalte in den Arbeitsbereich pullen können.
Geringfügige, häufige Änderungen: Eine bewährte Methode in Git besteht darin, kleine inkrementelle Änderungen vorzunehmen, die leicht zusammenzuführen sind und weniger wahrscheinlich in Konflikte geraten. Wenn dies nicht möglich ist, stellen Sie sicher, dass Sie Ihren Branch vom Mainbranch aktualisieren, damit Sie die Konflikte zuerst selbst beheben können.
Konfigurationsänderungen: Ändern Sie bei Bedarf die Konfigurationen in Ihrem Arbeitsbereich, damit Sie produktiver arbeiten können. Einige Änderungen können Verbindungen zwischen Elementen oder mit verschiedenen Datenquellen umfassen oder Änderungen an Parametern für ein bestimmtes Element. Denken Sie daran, dass alles, was Sie committen, versehentlich mit dem Mainbranch gemergt werden kann.
Verwenden von Clienttools zum Bearbeiten Ihrer Arbeit
Bei Elementen und Tools, die dies unterstützen, kann es einfacher sein, Clienttools für die Erstellung zu nutzen (z. B. Power BI Desktop für Semantikmodelle und Berichte oder VSCode für Notebooks). Diese Tools können als lokale Entwicklungsumgebung genutzt werden. Nachdem Sie Ihre Arbeit abgeschlossen haben, pushen Sie die Änderungen in das Remoterepository, und synchronisieren Sie den Arbeitsbereich, um die Änderungen hochzuladen. Stellen Sie sicher, dass Sie mit der unterstützten Struktur des Elements arbeiten, das Sie erstellen. Wenn Sie sich nicht sicher sind, klonen Sie zunächst ein Repository mit Inhalten, die bereits mit einem Arbeitsbereich synchronisiert wurden. Beginnen Sie dann dort mit der Erstellung, wo die Struktur bereits vorhanden ist.
Verwalten von Arbeitsbereichen und Branches
Da ein Arbeitsbereich jeweils nur mit einem einzelnen Branch verknüpft sein kann, empfiehlt es sich, dies als 1:1-Zuordnung zu behandeln. Um jedoch den Umfang des damit verbundenen Arbeitsbereichs zu reduzieren, sollten Sie die folgenden Optionen in Betracht ziehen:
Wenn ein Entwickler einen privaten Arbeitsbereich mit allen erforderlichen Konfigurationen eingerichtet hat, kann er diesen Arbeitsbereich weiterhin für jeden zukünftigen Branch verwenden, den er erstellt. Wenn ein Sprint abgeschlossen ist, Ihre Änderungen gemergt sind und Sie mit einer neuen Aufgabe beginnen, ändern Sie einfach die Verknüpfung in einen neuen Branch im selben Arbeitsbereich. Sie können dies auch tun, wenn Sie plötzlich mitten in einem Sprint einen Fehler beheben müssen. Stellen Sie sich einfach ein Arbeitsverzeichnis im Web vor.
Entwickler*innen, die ein Clienttool verwenden (z. B. VS Code oder Power BI Desktop), benötigen nicht unbedingt einen Arbeitsbereich. Sie können Branches erstellen und Änderungen an diesem Branch lokal committen, diese an das Remoterepository pushen und einen Pull Request für den Mainbranch erstellen, ohne dass Sie dazu einen Arbeitsbereich benötigen. Ein Arbeitsbereich wird nur als Testumgebung benötigt, um zu überprüfen, ob alles in einem realen Szenario funktioniert. Sie entscheiden, wann dies geschehen soll.
Duplizieren eines Elements in einem Git-Repository
So duplizieren Sie ein Element in einem Git-Repository
- Kopieren Sie das gesamte Elementverzeichnis.
- Ändern Sie die logische ID (logicalId) in einen eindeutigen Wert für diesen verbundenen Arbeitsbereich.
- Ändern Sie den Anzeigenamen, damit er sich vom Namen des ursprünglichen Elements unterscheidet und kein Fehler aufgrund von doppelten Anzeigenamen auftritt.
- Aktualisieren Sie bei Bedarf die logische ID (logicalId) und/oder die Anzeigenamen in Abhängigkeiten.
Test
Dieser Abschnitt bietet Empfehlungen für die Arbeit mit einer Testphase für Bereitstellungspipelines.
Simulieren Ihrer Produktionsumgebung
Es ist wichtig nachzuvollziehen, wie sich die vorgeschlagene Änderung auf die Produktionsphase auswirkt. In der Testphase für Bereitstellungspipelines können Sie eine echte Produktionsumgebung zu Testzwecken simulieren. Sie können diese Simulation alternativ nachbilden, indem Sie Git mit einem weiteren Arbeitsbereich verknüpfen.
Stellen Sie sicher, dass in Ihrer Testumgebung diese drei Faktoren berücksichtigt werden:
Datenmenge
Nutzungsumfang
Eine ähnliche Kapazität wie in der Produktion
Beim Testen können Sie dieselbe Kapazität wie in der Produktionsphase verwenden. Die Verwendung derselben Kapazität im Rahmen von Auslastungstest kann jedoch die Produktion instabil machen. Um eine instabile Produktion zu vermeiden, verwenden Sie für Tests eine andere Kapazität mit ähnlichen Ressourcen wie die Produktionskapazität. Um Zusatzkosten zu vermeiden, verwenden Sie eine Kapazität, für die nur im Testzeitraum Gebühren anfallen.
Verwenden von Bereitstellungsregeln mit einer realen Datenquelle
Wenn Sie die Testphase verwenden, um die Nutzung realer Daten zu simulieren, ist es am besten, die Entwicklungs- und Testdatenquellen zu trennen. Die Entwicklungsdatenbank sollte relativ klein sein, und die Testdatenbank sollte der Produktionsdatenbank so ähnlich wie möglich sein. Verwenden Sie Datenquellenregeln, um in der Testphase zwischen Datenquellen zu wechseln oder um die Verbindung zu parametrisieren, wenn Sie nicht mit Bereitstellungspipelines arbeiten.
Überprüfen zugehöriger Elemente
Ihre Änderungen können sich auch auf die abhängigen Elemente auswirken. Vergewissern Sie sich während der Tests, dass Ihre Änderungen die Leistung bestehender Elemente, die von den aktualisierten Elementen abhängen können, nicht beeinträchtigen.
Zugehörige Elemente lassen sich einfach mithilfe der Auswirkungsanalyse ermitteln.
Aktualisieren von Datenelementen
Datenelemente sind Elemente, in denen Daten gespeichert werden. Die Definition des Elements in Git legt fest, wie die Daten gespeichert werden. Beim Aktualisieren eines Elements im Arbeitsbereich importieren wir dessen Definition in den Arbeitsbereich und wenden sie auf die vorhandenen Daten an. Datenelemente werden bei Git und bei Bereitstellungspipelines auf dieselbe Weise aktualisiert.
Da verschiedene Elemente unterschiedliche Fähigkeiten aufweisen, wenn es um die Datenaufbewahrung bei der Änderung an der Definition geht, sollten Sie bei der Anwendung der Änderungen mit Sorgfalt vorgehen. Einige Methoden können helfen, die Änderungen auf möglichst sichere Weise anzuwenden:
Informieren Sie sich im Voraus über die Änderungen und ihre möglichen Auswirkungen auf die vorhandenen Daten. Verwenden Sie Commitnachrichten, um die vorgenommenen Änderungen zu beschreiben.
Um zu testen, wie das Element die Änderung mit Testdaten verarbeitet, laden Sie die Änderungen zuerst in eine Entwicklungs- oder Testumgebung hoch.
Wenn alles einwandfrei funktioniert, empfiehlt es sich, die Anwendung auch in einer Stagingumgebung mit realen Daten (oder möglichst realitätsnahen Daten) zu testen, um unerwartete Verhaltensweisen in der Produktion zu minimieren.
Überlegen Sie sich den besten Zeitpunkt für die Aktualisierung der Produktionsumgebung, um Beeinträchtigungen zu minimieren, die eventuelle Fehler bei Ihren Geschäftsanwendern verursachen könnten, die die Daten nutzen.
Nach der Bereitstellung sollten Tests in der Produktionsumgebung durchgeführt werden, um zu überprüfen, ob alles erwartungsgemäß funktioniert.
Einige Änderungen werden immer als Breaking Changes betrachtet. Die bisher beschriebenen Schritte sollen Ihnen helfen, diese bereits vor der Einführung in die Produktionsumgebung zu ermitteln. Planen Sie, wie die Änderungen in der Produktion angewendet und die Daten wiederhergestellt werden sollen, um den Normalzustand wiederherzustellen und die Downtime für Geschäftsbenutzer zu minimieren.
Testen Ihrer App
Wenn Sie Inhalte über eine App an Ihre Kunden verteilen, überprüfen Sie die neue Version der App, bevor sie in der Produktion eingesetzt wird. Da jede Phase der Bereitstellungspipeline über einen eigenen Arbeitsbereich verfügt, können Sie Apps problemlos für die Entwicklungs- und Testphase veröffentlichen und aktualisieren. Mit der Veröffentlichung und Aktualisierung von Apps können Sie die App aus der Sicht eines Endbenutzers testen.
Wichtig
Der Bereitstellungsprozess umfasst nicht die Aktualisierung der App-Inhalte oder -Einstellungen. Wenn Sie Änderungen an Inhalten oder Einstellungen durchführen möchten, aktualisieren Sie die App in der erforderlichen Pipelinephase manuell.
Produktion
Dieser Abschnitt bietet Empfehlungen für die Arbeit mit der Produktionsphase für Bereitstellungspipelines.
Verwalten der Bereitstellung für die Produktion
Die Bereitstellung in der Produktion sollte mit Umsicht erfolgen, deshalb gehört es zu den Best Practices, nur bestimmte Benutzer mit dieser sensiblen Aufgabe zu betrauen. Dennoch möchten Sie wahrscheinlich, dass alle BI-Ersteller für einen bestimmten Arbeitsbereich Zugriff auf die Pipeline erhalten. Verwenden Sie Berechtigungen für Arbeitsbereiche in der Produktion, um Zugriffsberechtigungen zu verwalten. Andere Benutzer können über eine Anzeigerolle für den Produktionsarbeitsbereich verfügen, sodass sie Inhalte im Arbeitsbereich einsehen, aber keine Änderungen an Git oder Bereitstellungspipelines vornehmen können.
Schränken Sie zusätzlich den Zugriff auf das Repository oder die Pipeline ein, indem Sie nur den Benutzern Berechtigungen erteilen, die an der Inhaltserstellung beteiligt sind.
Festlegen von Regeln zum Sicherstellen von Verfügbarkeit in der Produktionsphase
Bereitstellungsregeln sind eine leistungsstarke Möglichkeit, um sicherzustellen, dass stets eine Verbindung mit den Daten in der Produktion besteht, damit diese jederzeit für die Benutzer verfügbar sind. Durch die Anwendung von Bereitstellungsregeln kann die Bereitstellung erfolgen, während Sie sicher sein können, dass Kunden die relevanten Informationen ungestört einsehen können.
Legen Sie Produktionsbereitstellungsregeln für Datenquellen und Parameter fest, die im Semantikmodell definiert sind.
Aktualisieren der Produktions-App
Durch Bereitstellung in einer Pipeline über die Benutzeroberfläche wird der Arbeitsbereichsinhalt aktualisiert. Verwenden Sie die Bereitstellungspipeline-API, um die zugeordnete App zu aktualisieren. Es ist nicht möglich, die App über die Benutzeroberfläche zu aktualisieren. Wenn Sie eine App zur Verteilung von Inhalten verwenden, vergessen Sie nicht, die App nach der Bereitstellung in der Produktion zu aktualisieren, damit Endbenutzer sofort die neueste Version verwenden können.
Bereitstellen in der Produktion mithilfe von Git-Branches
Da das Repository eine „Einzige Quelle der Wahrheit“ (Single-Source-of-Truth, SSOT) darstellt, möchten einige Teams Updates in verschiedenen Phasen u. U. direkt aus Git bereitstellen. Dies ist mit der Git-Integration möglich, wenn man ein paar Dinge beachtet:
Die Verwendung von Releasebranches wird empfohlen. Sie müssen die Verknüpfung des Arbeitsbereichs mit den neuen Releasebranches vor jeder Bereitstellung kontinuierlich ändern.
Wenn Ihre Build- oder Releasepipeline erfordert, dass Sie den Quellcode ändern oder Skripte in einer Buildumgebung ausführen, bevor die Bereitstellung im Arbeitsbereich erfolgt, ist es nicht hilfreich, den Arbeitsbereich mit Git zu verbinden.
Stellen Sie nach der Bereitstellung in jeder Phase sicher, dass Sie die gesamte für diese Phase spezifische Konfiguration ändern.
Schnellkorrekturen an Inhalten
Manchmal gibt es Probleme in der Produktion, die eine schnelle Korrektur erfordern. Die Bereitstellung einer Fehlerkorrektur ohne vorherige Tests stellt keine gute Praktik dar. Implementieren Sie die Korrektur daher immer in der Entwicklungsphase, und übertragen Sie sie mithilfe von Push in die verbleibenden Phasen der Bereitstellungspipeline. Durch die Bereitstellung in die Entwicklungsphase können Sie überprüfen, ob die Korrektur funktioniert, bevor Sie sie in der Produktion bereitstellen. Die Bereitstellung in allen Phasen der Pipeline dauert nur wenige Minuten.
Wenn Sie die Bereitstellung aus Git verwenden, empfiehlt es sich, die unter Anwenden einer Git-Branchingstrategie beschriebenen Methoden zu befolgen.
Zugehöriger Inhalt
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für