Microsoft Power Platform Pipelines| Productivity News 1.4.2025

Wer mit der Power Platform arbeitet, kennt das Problem: Wie bringt man eine entwickelte Solution einfach von der Entwicklungsumgebung in eine Test- oder Produktiv-Umgebung? Genau hier setzen die Power Platform Pipelines an. Sie bieten eine Möglichkeit, Power Platform Solutions zu deployen, ohne dass man zuerst die Lösung manuell exportieren und in der Zielumgebung wieder importieren muss.

Für diesen Blog habe ich mich ein paar Stunden mit Pipelines befasst und teile nun meine Erkenntnisse. In einem ersten Schritt werde ich kurz erläutern, wie man eine neue Pipeline einrichtet und wie sie startet. Weitere Erkenntnisse werde ich dann den verschiedenen Deployment-Möglichkeiten gegenüberstellen und unseren Favoriten küren.

Wie kann ich mit Pipelines loslegen?

Wie immer in der Power Platform führen viele Wege nach Rom. Der prominenteste Ort, um mit einer Pipeline zu starten, ist, wenn man den Export einer Solution manuell starten möchte. Dort tauch seit längerer Zeit dieser Hinweis auf:

Wählt man «Start the deployment process», kommt man innerhalb der Solution auf den neuen Reiter «Pipelines», wo man eine Übersicht über die konfigurierten Pipelines erhält. Anfänglich ist das natürlich noch recht leer hier, es könnte aber mal so aussehen:

Obwohl man sich hier im Kontext in einer bestimmten Solution befindet, muss man sich bewusst sein, dass eine Pipeline immer für alle Solutions in diesem Environment angewendet werden können. Dies wurde mir erst im weiteren Verlauf meiner Tests so richtig bewusst, weil die erstellten Pipelines dann plötzlich in allen anderen Solutions auch auftauchen. Eine Pipeline definiert somit also nicht den ALM-Process einer bestimmten Solution, sondern den einer ganzen Umgebung.

Die Pipeline kann nun gestartet werden, indem man im Pipeline-Reiter den «Deploy here»-Button auf der ersten Stage wählt. Hier folgt nun die Möglichkeit, das Update gleich jetzt zu starten oder zu einem späteren Zeitpunkt zu planen. Anschliessend sind die Masken identisch zum manuellen Import einer Solution: 1. Review der Connections und 2. Manuelles Setzen der Umgebungsvariablen. Nachdem ein Release erfolgreich auf die nächste Stage deployed wurde, wird dann der «Deploy here» Button auf der nächsten Stage aktiv.

Somit ist ein kompletter Deployment-Zyklus abgeschlossen und die neuste Version ist in der produktiven Umgebung verfügbar.

Was sind die Vorteile?

Sobald man sich etwas in das Thema der Power Platform Pipelines eingefuchst hat, kann man relativ schnell eine generelle Deployment Lösung passend für seine Environment Strategie zusammenklicken. Zudem ist diese Lösung nahtlos in die Power Platform integriert und startet den Deployment-Prozess direkt aus der jeweiligen Solution heraus. Das ist praktisch und einfach.

Gibt es auch Nachteile?

Leider ja.

Kosten

Dem aufmerksamen Leser ist vielleicht nicht entgangen, dass auf dem Screenshot oben erwähnt ist, dass es sich beim Target Environment um ein Managed Environment handeln muss. Dies hat zur Folge, dass sämtliche User im Ziel-Environment mit Premium-Lizenzen der Power Platform ausgestattet sein müssen. Gerade im Umfeld der Canvas Apps mit SharePoint als Datenhaltung ist diese Lizenz bei den allermeisten Usern nicht vorhanden und erzeugt somit pro User und Stage ca. CHF 5.- Zusatzkosten pro Monat.

Fehlerhandling

Ich habe versucht, in meinem Test auch etwas komplexere Deployments zu provozieren, um der Realität etwas näher zu kommen. So habe ich zwischen den einzelnen Deployments neue Konnektoren hinzugefügt und PowerAutomate Workflows in der Canvas App hinzugefügt. Mit dem Resultat, dass ich inzwischen beim Deployment auf UAT folgenden Fehler erhalte:

{„error“:{„code“:“0x80040265″,“message“:“Something went wrong, please try again“}}

Um hier herauszufinden, wo das Problem liegt, müsste ich jetzt tiefer zu graben beginnen. Oder ich würde die Solution manuell exportieren / importieren, um zu prüfen, ob ich dort eine schlauere Fehlermeldung erhalten würde.

Umgebungsvariablen

Ich hätte mir tatsächlich erhofft, dass man die Umgebungsvariablen 1x definieren kann und diese dann bei den nächsten Deployments automatisch gesetzt würden. Dem ist leider nicht so. Ich muss jedes Mal wie beim herkömmlichen manuellen Import alle Variablen neu setzen. Dies ist durchaus eine häufige Fehlerquelle.

Datenmodell

Da es sich um Power Platform Pipelines handelt, werden auch nur Artefakte der Power Platform im Deployment berücksichtigt. Allfällige Änderungen an einem SharePoint Datenmodell können nicht integriert werden.

Gibt es Alternativen zu Power Platform Pipelines?

Ja: Azure DevOps Pipelines.

Seit einiger Zeit setzen wir in der IOZ auf die Azure DevOps Pipelines. Dies ist ein mächtiges Tool, welches seine Rechtfertigung üblicherweise im Einsatz bei grossen Software-Projekten findet. Hier braucht es sicher mehr Zeit, bis man sich in die Platform eingearbeitet hat. Oder aber man lässt sich ganz einfach von der IOZ dabei helfen. Durch die Vielfalt an möglichen Tools kann man sich eine massgeschneiderte Deployment Lösung zusammenbauen. Hier kann z.B. problemlos auch das SharePoint-Datenmodell mit Hilfe von PnP-Templates aktualisiert werden und weitere Tasks oder auch Approvals können ergänzt werden.

Da wir hier auf die Microsoft Power Platform CLI setzen, kann man sich auch sämtliche Umgebungsvariablen in einem Settings-File definieren. Diese werden dann beim Import direkt angewendet, eine grosse Fehlerquelle wird somit eliminiert. Azure DevOps gibt es sogar ohne Zusatzkosten, sofern man nicht Hunderte oder gar Tausende von Pipelines benötigt.

Konkretes Beispiel einer DevOps Pipeline.

Fazit

Die Idee der Power Platform Pipelines ist nett und alles ist schön integriert. Vielleicht habe ich dem Tool auch zu wenig Zeit gegeben, um es in der vollen Tiefe zu erkunden.

Wer also nicht ohnehin schon auf allen Umgebungen Premium-Lizenzen im Einsatz hat oder keinen Vorteil beim Einsatz der Managed Environments sieht, wird sich kaum für diese Pipelines entscheiden. Die Mehrkosten dürften die gewonnenen Vorteile nicht wirklich rechtfertigen.

Mit geübtem Händchen ist man zudem fast gleich schnell beim manuellen Export / Import einer Solution und die Vergabe der Variablen ist bei Pipelines und manuell gleich fehleranfällig. Für einen Grossteil der Kunden-Projekte, welche mir bei der IOZ begegnet sind, bilden diese Power Platform Pipelines daher nicht das langersehnte Puzzle-Stück im ALM-Prozess. Hier bleiben DevOps und der manuelle Ansatz klar die Favoriten.