„Wer darf das nach Prod schieben?" — Git-first mit Dataverse-Environments im Team

„Wer darf das eigentlich nach Prod schieben?” Sobald mehr als ein Maker an derselben Solution arbeitet, ist das keine Kleinigkeit mehr, sondern die Kernfrage. Und „wir machen das jetzt git-first” beantwortet sie nicht — im Gegenteil: Ohne Reihenfolge, Branch-Strategie und Rollen wird aus git-first schnell ein Repo, an das drei Umgebungen unkoordiniert committen und in dem niemand mehr weiß, welcher Stand nach Prod darf.

Die gute Nachricht: Seit die Git-Integration in Power Platform allgemein verfügbar ist (GA seit April 2025) und die Pipelines in Power Platform die Freigabe übernehmen, gibt es dafür einen dokumentierten, geradlinigen Weg. Man muss ihn nur in der richtigen Reihenfolge gehen. Der Reihe nach — für ein Team, nicht für den Einzelkämpfer.

Das Problem: „git-first” ist im Team kein „jeder committet”

Im Solo-Betrieb reicht: Umgebung an ein Repo hängen, committen, fertig. Im Team fallen genau die Fragen an, die der Einzelne nie stellt:

Wer arbeitet wo? Zwei Maker in derselben Dev-Umgebung überschreiben sich gegenseitig — die Solution ist der Stand, es gibt kein „meins” und „deins”.
Welche Umgebung hängt an welchem Branch? Wenn Dev, Test und Prod alle irgendwie mit Git verbunden sind, ist unklar, wo der maßgebliche Stand liegt.
Wer gibt frei? Wenn jeder Maker aus seiner Umgebung heraus nach Prod deployen kann, ist die Freigabe ein Klick — kein Review, kein Vier-Augen-Prinzip.

Git-first im Team heißt deshalb: eine klare Trennung, wer entwickelt, wer reviewt und wer freigibt — technisch abgesichert, nicht per Zuruf. Dafür muss man zuerst zwei Bausteine auseinanderhalten, die gern verwechselt werden.

Zwei Bausteine, die man nicht verwechseln darf

Der häufigste Denkfehler: „Git-Integration deployt nach Prod.” Tut sie nicht. Es sind zwei getrennte Features mit zwei getrennten Aufgaben:

Git-Integration — bindet eine Dev-Umgebung an ein Azure-DevOps-Repo und legt deine Solution dort als lesbaren Quelltext ab. Zuständig für Entwicklung und Versionierung. Ausdrücklich nur für Dev-Umgebungen gedacht, nicht für Test oder Prod. (Was sie genau tut, steht im Beitrag Git-Integration in Power Platform.)
Pipelines in Power Platform — nehmen ein gebautes managed Solution-Artefakt und reichen es kontrolliert durch die Stages bis Prod. Zuständig für Freigabe und Deployment.

Schema: Zwei getrennte Bausteine — Git-Integration bindet nur Dev-Umgebungen an das Azure-DevOps-Repo (unmanaged Quelltext, Branch je Umgebung), Pipelines bauen daraus ein managed Artefakt und deployen es durch Test/UAT/Prod. Git ist die Quelle, Pipelines sind der Kanal.

Merksatz: Git ist die Quelle, die Pipeline ist der Kanal. Nach Prod kommt nie ein Branch-Merge, sondern immer ein gebautes managed Artefakt. Wer das verinnerlicht, macht bei der Einrichtung nichts mehr grundlegend falsch.

Die Reihenfolge der Einrichtung

Die Reihenfolge ist nicht beliebig — jeder Schritt setzt den vorigen voraus. So sieht der dokumentierte Weg aus:

1. Managed Environments aktivieren

Die Git-Integration ist ein Feature von Managed Environments. Sowohl die Dev-Umgebungen als auch die Ziel-Umgebungen müssen im Power Platform Admin Center als Managed Environment aktiviert sein. Das ist Pflicht, kein Nice-to-have — ohne kommst du gar nicht erst zum Verbinden.

Feiner, aber wichtiger Unterschied: Reine Pipelines verlangen für Dev-Umgebungen kein Managed Environment. Sobald du aber Git-Integration und Pipelines kombinierst, gilt die strengere Git-Regel. (Ab Februar 2026 aktiviert Microsoft für Pipeline-Ziel-Umgebungen ohnehin automatisch Managed Environments.)

2. Azure-DevOps-Repo anlegen und initialisieren

Provider ist ausschließlich Azure DevOps Git — GitHub wird für die native Verbindung derzeit nicht unterstützt. Leg im Azure-DevOps-Projekt ein Git-Repo an und initialisiere es (Repos → Initialize). Ein nicht initialisiertes Repo hat keinen Default-Branch und quittiert das Verbinden mit einem Fehler („Failed to retrieve the default branch”).

Berechtigungen: In Dataverse brauchst du System Administrator, um die Bindung herzustellen. In Azure DevOps genügt Basic Access plus Mitgliedschaft in der Contributors-Gruppe des Repos.

3. Solution mit Git verbinden — und die Grundsatzentscheidung treffen

Im Maker-Portal unter Solutions erscheint Connect to Git. Hier fällt eine Entscheidung, die du früh und bewusst treffen solltest, weil sie den ganzen Team-Ablauf prägt:

Environment-Binding (von Microsoft als Einstieg empfohlen): Die gesamte Umgebung hängt an einem Repo, einem Ordner, einem Branch. Jede neue unmanaged Solution wird automatisch mitgesynct — kein weiterer Handgriff pro Solution.
Solution-Binding: Einzelne Solutions einer Umgebung lassen sich an verschiedene Branches/Ordner binden — mehr Flexibilität, aber jede neue Solution muss manuell onboardet werden. Einschränkung: Dasselbe Objekt darf nur an einer Stelle im Source Control liegen.

Die Default Solution (und die Common Data Service Default Solution) lassen sich per Design nicht mit Git verbinden — arbeite immer in einer eigenen, custom Solution.

Schema: Einrichtungsreihenfolge als Kette — (1) Managed Environment auf Dev + Ziel, (2) Azure-DevOps-Repo anlegen und initialisieren, (3) Connect to Git mit der Entscheidung Environment-Binding (ganze Umgebung, ein Branch, automatisch) vs. Solution-Binding (je Solution, flexibler, manuelles Onboarding).

4. Ein Dev-Environment pro Entwickler — an je einen Feature-Branch

Jetzt kommt der Team-Teil. Microsofts Referenzarchitektur sieht mehrere parallele Dev-Umgebungen vor (DEV1, DEV2, …) — im Idealfall eine pro Entwickler oder pro Arbeitsstrom. Jede dieser Umgebungen bindet an einen eigenen Branch. So arbeitet jeder isoliert, ohne dem anderen die Solution unter den Fingern wegzuändern.

Die naheliegenden, aber falschen Reflexe

Bevor wir zur Branch-Strategie kommen, drei Reflexe, die im Team teuer werden:

Reflex 1: „Wir hängen Dev, Test und Prod an Git und mergen die Config per Branch nach Prod.” Falsch. Git gehört nur an Dev-Umgebungen. Nach Prod wird nicht gemergt, sondern ein gebautes managed Artefakt deployt. Test und Prod sehen das Repo nie.

Reflex 2: „Jeder Maker deployt selbst aus seiner Umgebung nach Prod.” Genau das verhindert die Trennung. Die Freigabe läuft über eine Pipeline mit Genehmigung — der Maker startet, ein Approver entscheidet.

Reflex 3: „Ich committe selektiv nur meine eine Änderung.” Geht nicht: Ein Commit nimmt alle anstehenden Änderungen der Solution zusammen. Wer beim schnellen Fix nicht aufpasst, schiebt halbfertige Nachbararbeit mit hoch. Gegenmittel: Solutions klein schneiden und PRs klein halten.

Die belastbare Lösung: Branch-Strategie und Freigabe

Branch-Strategie: feature / main / release

Microsofts Referenzarchitektur nennt eine klassische, codifizierte Strategie mit drei Branch-Typen:

feature — je Entwickler/Arbeitsstrom ein Branch, an den seine Dev-Umgebung gebunden ist. Hier entsteht die Arbeit.
main — der maßgebliche Integrations-Branch. Was hier liegt, ist „bereit für den Weg nach Prod”. Niemand committet direkt hinein.
release — der Stand, der tatsächlich draußen ist; Basis für Hotfixes.

Der Ablauf: Feature-Branch → Pull Request → main. Damit main sauber bleibt, sichert Branch Protection ihn ab (kein Direkt-Push, PR-Pflicht, Reviewer-Pflicht). Und gegen „Feature Drift” — also das Auseinanderlaufen der vielen Dev-Umgebungen — ziehst du den in main gemergten Stand zurück in die Feature-Branches der anderen Entwickler.

Technischer Merkposten: Die native Git-Integration bindet pro Bindung genau einen Branch. Pull Requests, Merges und Branch-Wechsel passieren in Azure DevOps, nicht im Maker-Portal. Um in einer Umgebung einen anderen Branch-Stand zu ziehen, trennst du die Bindung und verbindest neu auf den Ziel-Branch — das ist der dokumentierte Weg.

Schema: Branch-Strategie — mehrere Dev-Umgebungen, je an einen Feature-Branch gebunden; Feature-Branches fließen per Pull Request (Branch Protection, Reviewer) in main; aus main entsteht der release-Stand; main wird in die Feature-Branches zurückgezogen, um Feature Drift zu vermeiden.

Wer macht die Pull Requests?

Die Entwickler machen die Pull Requests — von ihrem Feature-Branch nach main, in Azure DevOps. Der PR ist der Ort für das Review: Weil die native Git-Integration die Solution-Komponenten in einer für Git optimierten Struktur ablegt — insbesondere Tabellen, Spalten, Formulare und Ansichten als einzelne, lesbare YAML-Dateien —, zeigt der Diff fokussiert „diese Spalte kam dazu, diese View wurde geändert”, statt die Änderung in einer großen Customizations.xml suchen zu müssen. Die PR-Genehmigung ist damit ein inhaltliches Code-Review, kein Klick-durch. Azure DevOps liefert dazu die Governance: Branch Protection, Reviewer-Regeln, Audit-Trail.

Wichtig: Dieser PR-Merge bringt noch nichts nach Prod. Er konsolidiert nur den Quellstand in main. Der Weg nach Prod ist ein separater, kontrollierter Schritt.

Der König im Repo: ein Owner für `main`

Damit „jeder öffnet PRs” nicht im Chaos endet, braucht main einen klaren Owner — eine Person oder eine kleine Release-Owner-Gruppe (ein einzelner König ist ein Single Point of Failure). Diese Rolle verankerst du in Azure DevOps technisch über die Branch Protection von main:

Pflicht-Reviewer: Der Repo-Owner ist Required Reviewer jedes Pull Requests nach main — ohne seine Freigabe kein Merge.
Inhaltliches Review: Er liest den YAML-Diff — welche Komponenten ändern sich, ist die Solution sauber geschnitten, stimmen Connection References und Environment Variables.
Versionieren & dokumentieren: Mit dem Merge nach main entsteht ein Release-Kandidat. Der Owner vergibt die Solution-Version und hält in Release Notes fest, was drin ist — so ist jedes später gebaute Artefakt nachvollziehbar.
Freigabe für den Testlauf: Erst der Owner stößt Build und Deployment nach Test an (bzw. genehmigt es). Damit ist sauber getrennt: Entwickler schlagen vor (PR), der Owner entscheidet, was Release-Kandidat wird und in den Test geht.

So entsteht eine durchgehende Kette der Verantwortung: Der Entwickler besitzt seinen Feature-Branch, der Repo-Owner besitzt main und den Weg in den Test, der Prod-Approver (nächster Abschnitt) besitzt die letzte Tür vor Prod. Im kleinen Team darf der Repo-Owner zugleich der Prod-Approver sein; im Sinne des Vier-Augen-Prinzips ist es sauberer, beide Rollen zu trennen.

Wer gibt PROD frei?

Hier kommen die Pipelines in Power Platform ins Spiel — und ihre nativen Approvals. Der entscheidende Mechanismus heißt delegated deployments:

Ein Deployment läuft nicht mehr als der anfragende Maker, sondern als Service Principal.
Jede delegierte Deployment bleibt zunächst pending — sie wartet auf Genehmigung.
Die Genehmigung selbst hängst du an einen Power-Automate-Flow mit dem Trigger OnApprovalStarted und der Dataverse-Action UpdateApprovalStatus (Statuswert 20 = genehmigt, 30 = abgelehnt). So kannst du beliebige Freigabe-Logik einbauen — von „ein Approver genügt” bis „Freigabe nur im Change-Fenster”.

Damit ist die Rollen-Trennung technisch verankert:

Maker startet das Deployment mit wenigen Klicks aus seiner Dev-Umgebung — ohne ALM-Wissen.
Approver/Admin genehmigt oder lehnt ab; er entscheidet, was nach Prod geht.
Für die Pipeline-Verwaltung braucht es die Security-Rolle Deployment Pipeline Administrator; der Service Principal der delegierten Deployment braucht diese Rolle im Pipeline-Host und System Administrator in den Ziel-Umgebungen (sonst lassen sich z. B. Plug-ins nicht deployen).

Und weil die Pipeline die Solution einmal beim Deploy-Request exportiert und dasselbe Artefakt durch alle Stages schickt, kann niemand zwischendurch am Prod-nahen Stand vorbei „customizen” — die Freigabe lässt sich nicht umgehen.

Schema: Freigabeweg von Dev bis Prod — Commit aus der Dev-Umgebung, Pull Request des Entwicklers nach main (Review am YAML-Diff), Build eines managed Artefakts, Pipeline durch Test und UAT bis zum Prod-Gate; am Gate wartet die delegierte Deployment als pending, bis der Approver per Flow (UpdateApprovalStatus 20/30) genehmigt.

Der Weg eines Features — end to end

Entwickler arbeitet in seiner Dev-Umgebung, committet aus der Umgebung heraus auf seinen Feature-Branch.
Er öffnet in Azure DevOps einen Pull Request nach main; ein Kollege reviewt den YAML-Diff und genehmigt.
Aus main wird ein managed Artefakt gebaut — entweder aus der Dev-Umgebung exportiert oder aus dem Source Control gepackt:

# Managed Artefakt aus dem ausgecheckten main-Stand bauen
pac solution pack \
  --zipfile ./out/CustomerService_managed.zip \
  --folder ./ \
  --packagetype Managed

Die Pipeline reicht das Artefakt durch Test → UAT → Prod. In den Nicht-Dev-Umgebungen kommt ausschließlich managed an; Connections, Connection References und Environment Variables bindet die Pipeline dabei mit (dazu der Beitrag Connection References von Dev bis Prod).
Am Prod-Gate wartet die delegierte Deployment als pending — bis der Approver genehmigt. Erst dann geht es live.

Wo liegt das managed Artefakt? Nicht im Git-Repo — dort liegt nur der unmanaged Quelltext. Das managed Artefakt wird beim Deployment gebaut. Bei den Pipelines in Power Platform exportiert die Pipeline die Solution einmal und verwaltet dieses Artefakt im Dataverse-Pipeline-Host; dasselbe Artefakt durchläuft alle Stages (kein Re-Export, kein Tampering). Baust du stattdessen über Azure-DevOps-Pipelines, ist das managed .zip ein normales Pipeline-Artefakt des Build-Laufs — eine Azure-Artifacts-Feed (Package Registry) brauchst du dafür nicht, sie ist nur optional, wenn du Pakete versioniert aufbewahren und teamübergreifend teilen willst.

Zwei Wege nach Prod: Pipelines in Power Platform oder Azure DevOps

Egal welchen Weg du wählst — beide bauen das managed Artefakt aus demselben Git-Quellstand. Die Frage ist nicht „Git oder DevOps”, sondern welche Maschine das Deployment orchestriert. (Die Git-Integration liefert in beiden Fällen die Quelle; laut Doku lassen sich Pipelines sogar mit Azure DevOps oder GitHub kombinieren.)

	Pipelines in Power Platform	Azure-DevOps-Pipelines
Einrichtung	in-product, wenige Klicks	YAML-Pipelines + Power Platform Build Tools, Service Connection
Wer bedient es	Maker (ohne ALM-Wissen)	DevOps-/ALM-Rolle
Artefakt	im Dataverse-Pipeline-Host, einmal exportiert	Pipeline-Artefakt am Build-Lauf (Feed optional)
Freigaben	nativ: delegated deployments + Approval-Flow	ADO-Environments, Checks, Approvals
Build-Freiheit	begrenzt (feste Schritte, per Power Automate erweiterbar)	frei: Tests, Solution Checker, Code-First-Build, eigene Steps
Voraussetzung	Managed Environment (Ziel-Umgebungen)	Service Principal + Build-Agent
Typische Grenze	eine Dev-Umgebung je Solution, kein Multi-Solution je Lauf, keine Tabellendaten	mehr Setup und Pflege

Was man in beiden Fällen wissen muss:

In Nicht-Dev-Umgebungen kommt nur managed an; Connection References und Environment Variables bindest du über Deployment-Settings — nicht per Hand in Prod klicken.
Keine Dataverse-Tabellendaten reisen mit; beide Wege deployen Solutions plus Konfiguration, keine Zeilen.
Der Standard-Import ist ein Upgrade ohne „overwrite customizations” — das Rollback-Verhalten sollte man kennen.

Was jeweils speziell zu wissen ist:

Pipelines in Power Platform: Ziel-Umgebungen müssen Managed Environments sein (ab Februar 2026 aktiviert Microsoft das für Pipeline-Ziele automatisch). Die native Implementierung adressiert eine Dev-Umgebung je Solution — die Multi-Dev-/Feature-Branch-Parallelität kommt aus der Git-Integration, nicht aus der Pipeline.
Azure-DevOps-Pipelines: Du arbeitest mit den Power Platform Build Tools (Marketplace-Extension: export/pack/import/Solution Checker) und einer Service Connection (Service Principal). Eine Azure-Artifacts-Feed brauchst du nur für versionierte Aufbewahrung/Wiederverwendung, nicht für den Standardfluss.

Wann welcher Weg?

Pipelines in Power Platform — Low-Code-Teams, schneller Start, Maker-getriebene Freigabe, geradlinige Standard-Deployments.
Azure-DevOps-Pipelines — Pro-Code-/Fusion-Teams, automatisierte Tests und Quality Gates (Solution Checker), Code-First-Komponenten (PCF, Plug-ins), feingranulare CI/CD und Paket-Versionierung.
Viele Teams kombinieren beides: Git-Integration als Quelle + Pipelines in Power Platform für den Standardweg, und Azure-DevOps-Pipelines dort, wo automatisierte Tests oder ein eigener Build nötig sind.

Rollen- und Reihenfolge-Checkliste

Grenzen und die unbequemen Teile

Nur Azure DevOps. GitHub ist als nativer Provider (noch) nicht dabei — GitHub-Teams bleiben beim pac-Weg plus GitHub Actions, ohne die eingebaute Umgebungs-Bindung.
Nur Dev an Git. Test und Prod werden nie an Git gebunden; nach oben geht nur das gebaute managed Artefakt.
Managed Environment ist Pflicht für die Git-Integration — auf Dev und Ziel.
Keine selektiven Commits. Eine Solution committet alle anstehenden Änderungen zusammen — kleine Solutions und kleine PRs sind die Antwort.
Ein Branch pro Bindung. Multi-Branch-Parallelität entsteht durch mehrere gebundene Dev-Umgebungen plus Azure-DevOps-Branching — nicht durch das Portal allein.
Eine Dev-Umgebung pro Solution in Pipelines. Die native Pipeline adressiert pro Solution aktuell genau eine Dev-Umgebung; die Team-Parallelität kommt aus Git-Integration + Branching.
Kein Cross-Tenant. Dataverse-Tenant und Azure-DevOps-Tenant müssen zusammenfallen; Cross-Geo braucht eine explizite Zustimmung.

Kurz: Git-first im Team funktioniert — aber nicht als „jeder committet”, sondern als sauber getrennte Kette aus Entwicklung (Git-Integration, ein Dev-Env je Entwickler am Feature-Branch), Konsolidierung (Pull Request nach main mit echtem Review) und Freigabe (Pipeline mit delegierter Deployment und Approval-Gate vor Prod). Die Reihenfolge beim Einrichten und die Rollen bei der Freigabe sind dabei kein Formalismus — sie sind der Unterschied zwischen „wir arbeiten git-first” und „wir wissen jederzeit, wer was nach Prod gebracht hat”.

Stand: Juli 2026. Git-Integration ist GA seit April 2025; delegierte Deployments/Approvals sind nativ unterstützt. Microsoft entwickelt beide Features laufend weiter — im Zweifel die zugehörigen Learn-Seiten zu Git-Integration und Pipelines prüfen.