Governance und Administration

Power-BI-Deployment-Pipelines erstellen

So richten Sie eine Power-BI-Deployment-Pipeline ein: nötige Kapazität und Rechte, Schritte in Fabric, Deployment-Regeln und was Pipelines nicht leisten.

Austin Levine

·

Aktualisiert

Eine Deployment Pipeline kopiert Power-BI-Inhalte von einem Workspace in den nächsten, typischerweise von Development über Test nach Production, damit Sie Änderungen testen können, bevor Ihre Nutzer sie sehen. Um eine zu erstellen, müssen Sie Admin eines Workspaces sein. Jeder Workspace in der Pipeline muss außerdem auf einer Kapazität liegen, die Pipelines unterstützt: eine Fabric-F-Kapazität oder -Testversion, Premium Per User, eine Power-BI-Premium-P-Kapazität oder eine A- oder EM-SKU (die älteren Kapazitätsstufen von Power BI Embedded). Ein Workspace nur mit Pro kann nicht genutzt werden. Dann gehen Sie zu Workspaces > Deployment pipelines > Create pipeline, benennen Sie Ihre Stufen und weisen Sie jeder einen Workspace zu.

Was eine Deployment Pipeline leistet

Jede Stufe einer Pipeline ist ein Workspace. Beim Deployment kopiert Fabric die ausgewählten Elemente von der Quellstufe in die Zielstufe und überschreibt die passenden Elemente dort.

Pipelines leisten drei Dinge gut:

  • Umgebungen trennen. Entwickler arbeiten in Development, Tester prüfen in Test, und Fachanwender sehen immer nur Production.

  • Einstellungen pro Stufe ändern. Deployment-Regeln richten dasselbe Semantic Model in Test auf eine Testdatenbank und in Production auf die Produktionsdatenbank.

  • Änderungen sichtbar machen. Sie können zwei Stufen vor dem Deployment vergleichen und die Deployment-Historie jeder Stufe sehen.

Was Pipelines nicht leisten, ist Versionskontrolle. Es gibt kein Rollback auf eine frühere Version. Nutzen Sie dafür die Git-Integration von Fabric zusätzlich zur Pipeline.

Voraussetzungen

Voraussetzung

Detail

Kapazität

Jeder Workspace in der Pipeline braucht eine Fabric-Kapazität (F-SKU oder Testversion), eine P-Kapazität, PPU oder eine A- oder EM-SKU. PPU, A und EM funktionieren nur mit Power-BI-Elementen

Ihre Rolle

Admin des Workspaces, den Sie zuweisen möchten

Lizenzen

Pro oder PPU, um Power-BI-Inhalte in die Workspaces zu veröffentlichen

Semantic Models

Müssen das Format „Enhanced Metadata“ nutzen, das Modellformat, das aktuelle Versionen von Power BI Desktop standardmäßig speichern. Seit dem 12. Februar 2026 unterstützen Pipelines nicht aktualisierte Modelle nicht mehr

Wenn Sie PPU-Workspaces nutzen, können nur andere PPU-Nutzer den Inhalt öffnen. Für ein großes Publikum in Production ist eine Kapazität ab F64 meist die bessere Heimat der letzten Stufe. Warum, erklärt unser Leitfaden zu Power-BI-Lizenzen.

Schritt 1: Die Pipeline erstellen

  1. Öffnen Sie im Fabric-Portal das Flyout Workspaces und wählen Sie Deployment pipelines.

  2. Wählen Sie Create pipeline oder + New pipeline.

  3. Geben Sie einen Namen und eine Beschreibung ein und wählen Sie dann Next.

Sie können auch aus einem Workspace starten, den Sie verwalten, indem Sie Create deployment pipeline wählen. Dieser Workspace wird der Pipeline automatisch zugewiesen.

Schritt 2: Die Stufen festlegen

Die Pipeline startet mit drei Stufen: Development, Test und Production. Beim Einrichten können Sie sie umbenennen, Stufen hinzufügen oder entfernen, von 2 bis zu 10.

Entscheiden Sie sorgfältig. Sobald Sie Create wählen, steht die Anzahl der Stufen fest. Umbenennen können Sie die Stufen später weiterhin.

Schritt 3: Jeder Stufe einen Workspace zuweisen

Weisen Sie einer Stufe einen vorhandenen Workspace zu. Sie können einen Workspace zuweisen und ihn vorwärts deployen, um die anderen zu erzeugen, oder jeder Stufe einen anderen vorhandenen Workspace zuweisen.

Wenn Sie einen Workspace zuweisen, paart Fabric seine Elemente mit den passenden Elementen der Nachbarstufe. Gepaarte Elemente überschreiben sich beim Deployment gegenseitig. Nicht gepaarte Elemente erzeugen ein Duplikat, auch wenn sie denselben Namen haben. Das ist die häufigste Überraschung bei Pipelines. Weisen Sie Workspaces möglichst zu, bevor Sie Inhalte hinzufügen, und prüfen Sie, ob Elemente in der Pipeline-Ansicht auf derselben Zeile stehen.

Schritt 4: Inhalte deployen

Wählen Sie die Quellstufe und eine von drei Optionen:

  • Full deployment: alles in der Stufe deployen.

  • Selective deployment: die zu deployenden Elemente auswählen. Wählen Sie einen Report zusammen mit seinem Semantic Model, wenn sich beide geändert haben.

  • Backward deployment: von einer späteren Stufe in eine frühere deployen. Das funktioniert nur, wenn die Zielstufe leer ist.

Prüfen Sie den Vergleich, fügen Sie eine Notiz hinzu und wählen Sie Deploy.

Schritt 5: Deployment-Regeln hinzufügen

Mit Regeln behält jede Stufe ihre eigenen Einstellungen. Die häufigste Regel ändert in Test und Production die Datenquelle oder einen Parameter eines Semantic Models, sodass Development Beispieldaten abfragt und Production die vollständige Datenbank.

Um eine Regel zu erstellen, öffnen Sie die Zielstufe, wählen das Semantic Model und definieren die Regel. Regeln gelten ab dem nächsten Deployment. Sie müssen Besitzer des Semantic Models sein, um seine Regeln zu konfigurieren.

Automatisieren

Pipelines haben REST-APIs, sodass Sie Deployments aus Azure DevOps oder GitHub Actions auslösen können, nachdem Ihre Prüfungen bestanden sind. Beginnen Sie manuell, bis der Prozess stabil ist, und automatisieren Sie dann den Schritt von Test nach Production.

Häufige Probleme

  • Ein Deployment hat Duplikate erzeugt. Die Elemente waren nicht gepaart. Siehe Schritt 3.

  • Ein Semantic Model lässt sich nicht deployen. Prüfen Sie, ob es Enhanced Metadata nutzt und ob DirectQuery- oder Composite-Modelle keine automatischen Datums-/Zeittabellen enthalten. Pipelines unterstützen diese nicht.

  • Ein neu deploytes Semantic Model ist leer. Das Deployment kopiert Elementdefinitionen, keine Daten. Aktualisieren Sie das Semantic Model in der Zielstufe nach dem ersten Deployment.

  • Regeln wurden nicht angewendet. Regeln wirken ab dem nächsten Deployment und nur, wenn Sie das Semantic Model besitzen.

Wie Workspaces, Rollen und Apps rund um eine Pipeline zusammenspielen, steht in unserem Leitfaden zu Power-BI-Workspaces und Apps. Wenn Sie gleichzeitig entscheiden, ob Sie auf Fabric-Kapazität wechseln, lesen Sie Warum Microsoft Fabric.

FAQs

Brauche ich Power BI Premium für Deployment Pipelines?

Sie brauchen eine Kapazität oder einen Lizenztyp, der sie unterstützt: eine Fabric-F-Kapazität oder -Testversion, PPU, eine P-Kapazität oder eine A- oder EM-SKU. Pro allein reicht nicht. Weil Microsoft die P-SKUs einstellt, nutzen neue Setups normalerweise eine F-Kapazität oder PPU.

Wie viele Stufen kann eine Pipeline haben?

Von 2 bis 10. Standard sind drei: Development, Test und Production. Die Anzahl lässt sich nach dem Erstellen der Pipeline nicht ändern, Stufen lassen sich aber umbenennen.

Kann ich ein Deployment zurückrollen?

Nicht direkt. Pipelines führen eine Deployment-Historie, aber keine früheren Versionen zum Wiederherstellen. Verbinden Sie den Development-Workspace mit Git, stellen Sie die frühere Version aus dem Repository wieder her und deployen Sie sie erneut vorwärts.

Aktualisieren Deployment Pipelines Daten?

Nein. Sie kopieren Elementdefinitionen, keine Daten. Aktualisieren Sie ein Semantic Model in der Zielstufe, nachdem es dort zum ersten Mal deployt wurde, und nach jeder Änderung, die eine Aktualisierung braucht.

Quellen

Zeigen Sie uns Ihren Report, dem niemand traut.

1 · Ein Gespräch von 30 Minuten.

2 · Wir sehen uns gemeinsam Ihre aktuellen Reports an.

3 · Wir sagen Ihnen, was wir tun würden.

Zeigen Sie uns Ihren Report, dem niemand traut.

1 · Ein Gespräch von 30 Minuten.

2 · Wir sehen uns gemeinsam Ihre aktuellen Reports an.

3 · Wir sagen Ihnen, was wir tun würden.

Zeigen Sie uns Ihren Report, dem niemand traut.

1 · Ein Gespräch von 30 Minuten.

2 · Wir sehen uns gemeinsam Ihre aktuellen Reports an.

3 · Wir sagen Ihnen, was wir tun würden.

CaseWhen ist eine BI-Beratung aus Berlin. Wir bauen Reporting, dem die Geschäftsführung vertraut, auf dem Microsoft-Stack: Power BI, Fabric und Azure.

Berlin, Deutschland

© CaseWhen Consulting GmbH

Deutsch

CaseWhen ist eine BI-Beratung aus Berlin. Wir bauen Reporting, dem die Geschäftsführung vertraut, auf dem Microsoft-Stack: Power BI, Fabric und Azure.

Berlin, Deutschland

© CaseWhen Consulting GmbH

Deutsch

CaseWhen ist eine BI-Beratung aus Berlin. Wir bauen Reporting, dem die Geschäftsführung vertraut, auf dem Microsoft-Stack: Power BI, Fabric und Azure.

Berlin, Deutschland

© CaseWhen Consulting GmbH

Deutsch