Power Platform ALM mit Azure DevOps

So gelingt das Setup

Theorie ist gut – Praxis ist besser. Im ersten Teil hat unsere Power Platform Expertin, Daniela Zurwerra, den Grundstein gelegt und die Idee hinter Application Lifecycle Management (ALM) in der Power Platform beleuchtet. Jetzt wird’s praktisch.

Denn wer Low-Code ernsthaft in bestehende Entwicklungs- und Governance-Strukturen integrieren will, braucht mehr als gute Absichten. Es geht um ein Zusammenspiel aus Plattformen, Berechtigungen und Prozessen, das sauber aufgesetzt sein will – vom ersten Login bis zur laufenden Pipeline.

In diesem Beitrag zeigen wir, wie aus Konzept Routine wird: Wir richten die notwendigen Komponenten ein, verbinden die Power Platform mit Azure DevOps und erstellen einen ersten automatisierten Ablauf – eine sogenannte Pipeline, die Lösungen exportiert, versioniert und ablegt. Schritt für Schritt, nachvollziehbar und mit Blick auf das Wesentliche.

Vorraussetzungen

Bevor es losgeht, müssen einige Grundlagen geschaffen werden. Damit Azure DevOps mit der Power Platform interagieren kann, braucht es ein paar zentrale Bausteine:

• Entra App Registration

• Power Platform Environments

• Power Platform Application User

• Azure DevOps

  
  

Sind diese Komponenten eingerichtet und richtig konfiguriert, lassen sich Solutions versioniert ablegen – auch außerhalb des eigenen Tenants – oder zwischen Entwicklungs- und Testumgebungen migrieren.

Doch ein Schritt nach dem anderen.

Entra App Registration

Die Entra App Registration dient ausschließlich der Authentifizierung – Berechtigungen auf App oder Umgebung werden hier nicht gesetzt.

Im Microsoft Entra Admin Center geht man zu App registrations → New registration und vergibt einen Namen. Alle übrigen Einstellungen bleiben im Standard.

Danach folgt das Anlegen eines Secrets über Certificates & secrets.

Wichtig: Der Secret Value wird nur einmal angezeigt – also unbedingt sichern, bevor das Fenster geschlossen wird.

Abschließend sollten unter Overview Application ID und Tenant ID notiert werden.

Damit ist die Entra App Registration abgeschlossen – Zeit, den Blick auf die nächsten Schritte zu richten.

Power Platform Environments

Nachdem die App-Registrierung abgeschlossen ist, folgt die Einrichtung der Umgebungen in der Power Platform – sie bilden die Grundlage für ein strukturiertes und nachvollziehbares Application Lifecycle Management. Welche und wie viele Umgebungen erforderlich sind, hängt von der jeweiligen Projektarchitektur ab.

In der Praxis hat sich ein dreistufiges Modell bewährt:

• Dev – hier findet die Entwicklung statt.

• Test – nach Abschluss der Entwicklung wird die Lösung hier geprüft und validiert.

• Prod – die produktive Umgebung, in der die Lösung genutzt wird; direkte Anpassungen erfolgen hier nicht.

• 
  

Bei der Arbeit mit verwalteten Umgebungen empfiehlt sich zusätzlich eine Build-Umgebung. Dort wird die unverwaltete Lösung aus Dev exportiert, in Build importiert und anschließend als verwaltete Lösung in Test übertragen.

Die Einrichtung erfolgt im Power Platform Admin Center (https://admin.powerplatform.microsoft.com/). Über den Menüpunkt Manage lassen sich bestehende Umgebungen verwalten, über New neue anlegen. Dabei werden Name, Umgebungstyp und Modus – verwaltet oder unverwaltet – definiert. Entscheidend sind vor allem zwei Faktoren: Einsatzzweck und Lizenzmodell.

Detaillierte Empfehlungen bietet MS Learn: Environments. In den meisten Fällen werden Dev-, Test- und Build-Umgebungen als Sandbox oder Developer-Typ ausgeführt, während die produktive Umgebung als Production eingerichtet wird.

Stehen nur Developer-Lizenzen zur Verfügung, laufen die Umgebungen automatisch als Typ Developer. Dabei ist zu beachten, dass Developer-Umgebungen bei längerer Nichtnutzung deaktiviert und anschließend gelöscht werden können.

Verwaltete Umgebungen

Im Zusammenhang mit produktiven Umgebungen taucht häufig der Begriff „verwaltete Umgebung“ auf. Dabei handelt es sich nicht um einen eigenen Umgebungstyp, sondern um ein zusätzliches Feature, das auf einer bestehenden produktiven Umgebung aktiviert wird.

Verwaltete Umgebungen erweitern die Power Platform um verschiedene Sicherheits- und Verwaltungsfunktionen. So lässt sich beispielsweise der Zugriff über IP-Firewalls gezielt einschränken, und es stehen erweiterte Backups mit bis zu 28 statt 7 Tagen zur Verfügung. Darüber hinaus können hier verwaltete Lösungen betrieben werden, die keine direkte Bearbeitung der Anwendung zulassen und so eine höhere Stabilität gewährleisten.

Ein weiterer zentraler Vorteil: Wer in der Power Platform Pipelines nutzt, um Lösungen automatisiert von einer Umgebung in eine andere zu übertragen, benötigt dafür zwingend verwaltete Umgebungen. Ohne dieses Feature ist ein solcher automatisierter Deployment-Prozess nicht möglich.

Zu beachten ist, dass für verwaltete Umgebungen Premiumlizenzen erforderlich sind. Diese bieten zwar erweiterte Funktionalitäten und Sicherheit, können jedoch auch spürbare Kosten verursachen und sollten daher gezielt eingeplant werden.

Application User

Als nächster Schritt wird der Application User eingerichtet. Dabei handelt es sich um einen Service-User, über den die Power Platform mit externen Systemen kommuniziert – etwa mit Azure DevOps. Der Application User erhält die erforderlichen Berechtigungen für die jeweilige Umgebung und stellt die Verbindung zur Entra App Registration her.

Die Einrichtung erfolgt im Power Platform Admin Center. In der gewünschten Umgebung wird der Bereich Users geöffnet und anschließend der Unterpunkt Application users ausgewählt. Im Dialog wird eine App hinzugefügt, die zuvor erstellte Entra App Registration ausgewählt sowie eine Business Unit und eine Sicherheitsrolle definiert.

Als Business Unit wird in der Regel der Eintrag verwendet, der mit „orga“ beginnt. Als Sicherheitsrolle empfiehlt sich meist System Administrator.

Mit diesem Application User ist die Power Platform über die Entra App mit externen Systemen verbunden. Auf diese Weise lässt sich gezielt steuern, welche Umgebung später über Azure DevOps angebunden wird.

Für eine saubere Dokumentation ist es sinnvoll, die Environment URLs aller Umgebungen separat zu notieren und mit der jeweiligen Umgebung zu kennzeichnen, zum Beispiel: Test-Demo – orgaa440571.crm4.dynamics.com

So bleibt jederzeit nachvollziehbar, welche Verbindung zu welcher Umgebung gehört.

Azure DevOps

Sind alle Vorbereitungen in der Power Platform abgeschlossen, folgt die Einrichtung in Azure DevOps. Hier werden die Verbindungen hergestellt und die Basis für die späteren Automatisierungen geschaffen.

Power Platform Extension

Damit Azure DevOps mit Power Platform-Umgebungen arbeiten kann, müssen zunächst die passenden Tools installiert werden. Dies geschieht über die Organisations-Einstellungen im Bereich Extensions. Dort steht die Erweiterung Power Platform Build Tools zur Verfügung, mit der sich Lösungen exportieren, importieren und verwalten lassen.

Service Connection

Im nächsten Schritt wird die Verbindung zwischen Azure DevOps und der Entra App Registration eingerichtet.

Dazu wird im Projekt unter Settings → Pipelines → Service Connections eine neue Verbindung angelegt. Über New Service Connection wird der Typ Power Platform ausgewählt.

Anschließend werden die erforderlichen Verbindungsparameter eingetragen:

• Authentication method: Application ID and client secret

• Server URL: URL der jeweiligen Umgebung

• Tenant ID, Application ID & Client Secret: Werte aus der Entra App Registration

• Service Connection Name: Bezeichnung der Verbindung – idealerweise mit Umgebungsnamen, um den zugehörigen Service Principal später eindeutig zuordnen zu können.

Ist alles gespeichert, steht die Verbindung zwischen Azure DevOps und der Power Platform.

Agent Pools

Automatisierungen in Azure DevOps werden über sogenannte Agenten ausgeführt, die die einzelnen Aufgaben übernehmen. Diese Agenten können entweder direkt über Azure bereitgestellt oder lokal auf eigenen Systemen betrieben werden.

Für Standard-Szenarien sind Azure Pipelines in der Regel ausreichend: Sie sind integriert, leicht zu verwalten und erfüllen die meisten Anforderungen. Bei höheren Sicherheitsanforderungen lassen sich über Project Settings → Pipelines → Agent Pools eigene Agenten anlegen – etwa, um die Ausführung auf unternehmensinterne Server zu verlagern.

Die erste Pipeline

Sind alle Vorbereitungen abgeschlossen, kann in Azure DevOps die erste Pipeline erstellt werden – also ein automatisierter Ablauf, der bestimmte Aufgaben selbstständig ausführt. In diesem Fall soll sie eine Solution sichern und später weiterverarbeiten.

Ziel und Aufbau

Die Pipeline übernimmt also zwei Aufgaben:

1. Sie exportiert die Solution und legt sie als ZIP-Datei im Repository ab.

2. Sie legt eine weitere, entpackte Solution in einem separaten Verzeichnis ab.

Um die Dateien zu speichern, werden im Repository des Projekts zwei Unterordner angelegt: solution und sourcecode.

Pipeline – erste Schritte und Setup

Die erste Pipeline bildet den beschriebenen Anwendungsfall für die Dev‑Umgebung ab: Sie exportiert die Solution, legt sie als ZIP ab und stellt die entpackten Dateien für die Weiterverarbeitung im Repository bereit.

Erstellung

Für dieses Szenario empfiehlt sich der Classic Editor statt YAML. Nach dem Klick auf „New Pipeline“ fragt Azure DevOps, wo sich der Code befindet: hier „Azure Repos Git“ wählen. Anschließend werden Projekt, Repository und der gewünschte Branch angegeben.

Im nächsten Schritt kann ein Template ausgewählt werden. Als Vorlage für dieses Beispiel eignet sich jedoch „Empty Job“ – so beginnt die Pipeline leer und nur die benötigten Tasks werden hinzugefügt. Das erzeugt Klarheit und vermeidet unnötige Schritte.

Variable anlegen

In der leeren Pipeline wird zunächst eine Variable definiert, mit der der Name der Solution flexibel übergeben werden kann.Wichtig: Die Option „Settable at queue time“ aktivieren. Damit kann der Wert beim Start der Pipeline direkt in der Queue angepasst werden – ohne die Pipeline selbst ändern zu müssen.

Pipeline-Einstellungen

Im Menüpunkt Pipeline lassen sich Name, Agent Pool und Agent Specification festlegen. Agenten können entweder von Azure bereitgestellt (Microsoft-hosted) oder auf eigenen Systemen betrieben (self-hosted) werden. Letzteres ist vor allem dann sinnvoll, wenn besondere Sicherheitsvorgaben gelten.

Bevor die Tasks auf die Power Platform zugreifen können, muss das Skript Zugriff auf das OAuth‑Token erhalten: Option „Allow scripts to access the OAuth token“ aktivieren.

Tasks

Nun folgt die Einrichtung der einzelnen Tasks in dieser Reihenfolge:

1. Power Platform Tool Installer

Installiert die Power Platform Build Tools auf dem Agenten und schafft so die technische Grundlage für die nächsten Schritte.

2. Power Platform Export Solution

   Exportiert die gewünschte Solution.

   1. Authentifizierungstyp: Service Principal (ermöglicht die Nutzung der zuvor angelegten Service Connection).

   2. Solution Name: Variable aus dem vorherigen Schritt.

   3. Output File: Zielverzeichnis, z. B. der zuvor erstellte Ordner solution/$(SolutionName).zip.

3. Power Platform Unpack Solution

   Entpackt die exportierte ZIP-Datei in das Verzeichnis sourcecode/, wo sie im Unterordner der jeweiligen Solution abgelegt wird.

4. Command Line Script

   Führt den abschließenden Commit im Repository durch.

   
   

   Das Skript enthält Angaben zu Benutzername, E-Mail-Adresse, Branch (z. B. main), den hinzuzufügenden Dateien (in der Regel alle) und der Commit-Nachricht.

Sobald alle Tasks eingerichtet sind, wird die Pipeline gespeichert und über „Save & queue“ gestartet. Vor dem Ausführen sollte überprüft werden, dass die Variable SolutionName korrekt gesetzt ist.

Und nun — wie geht es weiter?

Die erste Pipeline bildet die Basis für weitere Automatisierungen. Auf ihrer Grundlage lassen sich zusätzliche Pipelines einrichten, die Solutions automatisiert zwischen Umgebungen promoten, Backups erzeugen oder Artefakte für Deployments vorbereiten. Diese Variante funktioniert ohne Zusatzkosten für Power Automate-Premium-Lizenzen und reduziert manuellen Aufwand nachhaltig.

Zudem ist die Lösung tenant-flexibel: Eine Azure-DevOps-Organisation muss nicht im selben Tenant wie die Power-Platform-Umgebungen liegen — vorausgesetzt, Service Principal / Service Connection und die nötigen Berechtigungen sind korrekt konfiguriert.

Im nächsten Teil der Serie geht es um Testing: welche Testarten sinnvoll sind, wie Testdaten & Testumgebungen eingerichtet werden sollten und welche Automatisierungsansätze sich im Low-Code-Umfeld bewährt haben.

Zusammenfassung für Eilige

Praktische Schritt-für-Schritt-Anleitung zum Aufsetzen von ALM mit der Power Platform und Azure DevOps — inklusive Entra-App, Umgebungsstruktur, Application-User-Konfiguration und der ersten automatisierten Pipeline. Das Ergebnis: wiederholbare, nachvollziehbare Deployments, geringerer manueller Aufwand, bessere Governance und Tenant-Flexibilität — ohne unnötige Zusatzkosten durch Power-Automate-Premium. Ideal für Entscheider und technische Verantwortliche, die Low-Code-Projekte skalierbar und sicher machen wollen.