Ein sauberes Solution-Modell ist die Grundlage dafür, dass ein Dynamics-365-System über Jahre wartbar bleibt und ohne Reibung wächst. Die zentrale Regel lautet: in Entwicklungsumgebungen wird unmanaged gearbeitet, in Test und Produktion wird ausschliesslich als Managed Solution deployt. Die managed Version entsteht durch Export der unmanaged als managed und wird wie ein Build-Artefakt behandelt. Dieser Artikel zeigt, wie Sie Solutions strukturieren, Umgebungen trennen, umgebungsabhängige Werte entkoppeln und den Rollout automatisieren.
Managed und Unmanaged Solutions als Fundament
Eine Solution ist der Container für alles, was Sie an Dynamics 365 anpassen: Tabellen, Spalten, Formulare, Business Rules, Plugins, Cloud Flows und mehr. Sie existiert in zwei Ausprägungen, und der Unterschied bestimmt Ihre gesamte ALM-Strategie.
Unmanaged und Managed im Vergleich
Eine Unmanaged Solution ist der offene Arbeitsstand in der Entwicklungsumgebung. Hier legen Sie Komponenten an, ändern und löschen sie.
Eine Managed Solution ist das geschlossene Auslieferungspaket, das in nachgelagerte Umgebungen importiert und dort nicht direkt editiert wird. Microsoft ist in der offiziellen Anleitung zum Organisieren von Solutions eindeutig: Unmanaged nur in der Entwicklung, managed für jede andere Umgebung.
Die Managed Solution als Build-Artefakt
Der wichtigste Grundsatz dahinter: Die Managed Solution ist ein Build-Artefakt. Sie exportieren die unmanaged Solution als managed und deployen genau dieses Paket weiter, statt in jeder Umgebung von Hand nachzubauen. So bleibt reproduzierbar, was in der Produktion landet.
Ein Publisher, ein Präfix
Legen Sie genau einen Solution Publisher mit einem konsistenten Anpassungspräfix an, etwa "alr" statt des voreingestellten "new". Das Präfix taucht im logischen Namen jeder eigenen Komponente auf und macht auf einen Blick sichtbar, was Standard ist und was Ihre Anpassung.
Warum die Publisher-Zuordnung bleibt
Dahinter steht ein handfestes Risiko. Der Publisher besitzt die Komponenten einer Managed Solution, und diese Zuordnung lässt sich später nicht mehr ändern. Wird eine Tabelle über Publisher X managed ausgeliefert, kann sie nicht auf Publisher Y umziehen.
Der einzige Ausweg wäre Löschen und Neuanlegen, was laut Microsoft zum Verlust aller Daten in dieser Tabelle führt, sofern nicht vorher migriert wird. Wer von Beginn an einen Publisher festlegt, umgeht dieses Problem vollständig.
Umgebungen trennen: Dev, Test, Prod
ALM braucht getrennte Dataverse-Umgebungen. Als Minimum gelten drei Stufen: Entwicklung, Test und Produktion. In der Entwicklung entstehen die Anpassungen unmanaged, in Test wird die managed Solution gegen echte Daten und Prozesse geprüft, in Produktion läuft der geprüfte Stand. Direkt in der Produktion zu entwickeln ist ein klassisches Anti-Pattern, das früher oder später Ausfälle produziert.
Wie viele Solutions brauchen Sie?
Wie viele Solutions Sie brauchen, hängt von der Grösse ab. Microsoft beschreibt drei Strategien, von einfach bis komplex:
- eine einzige Solution,
- mehrere Solutions in einer Entwicklungsumgebung und
- mehrere Solutions mit je eigener Entwicklungsumgebung.
Für die meisten mittleren Projekte reicht eine einzige Solution, die als managed Paket deployt wird. Grosse, modulare Vorhaben mit mehreren Teams profitieren von einer gemeinsamen Basis-Solution, auf der app-spezifische Layer aufsetzen.
Layering mit einer Basis-Solution
Das Layering funktioniert dabei nach einem klaren Muster. In einer Basis-Umgebung liegen die gemeinsamen Tabellen wie Konto und Kontakt in einer Basis-Solution, die als managed exportiert wird. Diese managed Basis importieren Sie in die jeweilige App-Entwicklungsumgebung und bauen darauf eine eigene unmanaged App-Solution, die das Datenmodell erweitert.
In der Produktion importieren Sie zuerst die Basis, dann die App-Layer. So arbeiten mehrere Teams parallel, ohne sich gegenseitig zu überschreiben, und trotzdem bleiben die Abhängigkeiten sauber definiert. Halten Sie die Zahl der Solutions dennoch so klein wie möglich, damit das Layering überschaubar bleibt.
Solution-Segmentierung
Bei sehr grossen Solutions hilft Segmentierung: Sie nehmen nur die wirklich geänderten Komponenten in ein Paket auf, statt jede Tabelle mit allen Spalten mitzuschleppen. Das verkürzt Import- und Deployzeiten spürbar. Halten Sie sich dabei an drei Regeln aus der Microsoft-Guidance: Nur eine Solution sollte alle Tabellen enthalten, kein Component gehört in zwei Solutions gleichzeitig, und Abhängigkeiten zwischen Solutions sollten Sie vermeiden. Solche Querabhängigkeiten sind die häufigste Ursache für Importfehler in der Produktion, ein Fehlerbild, das unser Beitrag zum Beheben einer Missing-Dependency beim Solution-Import Schritt für Schritt auflöst.
Konfiguration entkoppeln mit Environment Variables und Connection References
Sobald Sie über mehrere Umgebungen deployen, stehen Sie vor einem Problem: Manche Werte unterscheiden sich je Umgebung. Eine API-Ziel-URL zeigt in Test woanders hin als in Produktion, ein Cloud Flow soll in Dev eine andere Verbindung nutzen. Genau dafür gibt es zwei Mechanismen.
Konfigurationswerte über Environment Variables
Environment Variables speichern Konfigurationswerte wie URLs, Keys, Zahlen oder eine SharePoint-Site als eigene Solution-Komponente. Laut Microsoft ist es Best Practice, die Definition in der Solution mitzuliefern, den konkreten Wert aber erst beim Import zu setzen. So bleibt dieselbe Solution über alle Umgebungen identisch, und nur der Wert wandert mit. Details liefert die Microsoft-Dokumentation zu Environment Variables.
Verbindungen über Connection References
Connection References tun dasselbe für Verbindungen. Ein Cloud Flow verweist nicht auf eine feste Verbindung, sondern auf eine Referenz, die pro Umgebung aufgelöst wird. Wichtig ist die Abgrenzung: Eine Environment Variable transportiert Parameter, eine Connection Reference die Verbindung selbst.
Beide zusammen sorgen dafür, dass nach dem Import keine manuelle Nacharbeit an Apps oder Flows nötig ist. Beachten Sie dabei: Solutions transportieren nie Ihre Geschäftsdaten in Dataverse-Tabellen. Für den Umzug von Bestandsdaten brauchen Sie einen eigenen Prozess, wie ihn unser Leitfaden zur Dynamics-365-Datenmigration beschreibt.
Automatisiert deployen mit Power Platform Pipelines
Der manuelle Export-Import-Zyklus ist fehleranfällig und langsam. Power Platform Pipelines bringen automatisiertes ALM direkt in den Dienst, ohne dass Sie Azure DevOps von Grund auf aufbauen müssen. Ein Maker deployt seine Solution per Klick aus der Entwicklungsumgebung durch die definierten Stufen bis in die Produktion.
Vorabvalidierung und unveränderliches Artefakt
Der entscheidende Vorteil ist die Vorabvalidierung: Fehlende Abhängigkeiten, Verbindungen und Environment Variables werden vor dem Deployment erkannt und gemeldet, statt erst im Zielsystem zu scheitern. Das Solution-Artefakt wird beim Start der Anforderung exportiert und durchläuft die Stufen unverändert, es kann also keine QA-Stufe überspringen.
Zwei Punkte aus der offiziellen Pipelines-Übersicht sind planungsrelevant:
- Pipelines deployen nur managed, nicht unmanaged, und
- alle beteiligten Zielumgebungen müssen Managed Environments sein.
Ab Februar 2026 aktiviert Microsoft für Pipeline-Zielumgebungen automatisch Managed Environments, was entsprechende Lizenzen voraussetzt.
Governance mit Genehmigungen und Rollback
Für sensible Produktivumgebungen lassen sich delegierte Deployments mit Genehmigungsschritt konfigurieren, sodass ein Deployment erst nach Freigabe und über ein Service Principal ausgeführt wird. Jede Bereitstellung wird automatisch als Backup gesichert, und bei aktivierter Einstellung können Sie auf eine frühere Solution-Version zurückrollen.
Für Fachanwender bleibt der Ablauf trotzdem ein Klick, während Administratoren die Leitplanken zentral vorgeben. Genau diese Kombination aus Einfachheit und Governance macht Pipelines für die meisten Teams zur ersten Wahl, bevor komplexere CI/CD-Werkzeuge nötig werden.
Source Control und Git-Integration
Für Teams, die Änderungen versionieren und im Vier-Augen-Prinzip prüfen wollen, bietet Dataverse eine native Git-Integration. Entwicklungsumgebungen synchronisieren ihre unmanaged Solutions direkt mit einem Azure-DevOps-Git-Repository, inklusive Änderungsverfolgung, Code-Reviews und Wiederaufbau kurzlebiger Umgebungen aus dem Repository.
Source Control als Quelle der Wahrheit
Damit wird Source Control zur Quelle der Wahrheit statt der Maker-Umgebung. Die Übersicht zur Git-Integration stellt klar: Git ist für Entwicklungsumgebungen gedacht, während Test und Produktion über Pipelines beliefert werden. Für 2026 ist zusätzlich GitHub als Git-Provider vorgesehen, neben dem bereits verfügbaren Azure DevOps. Beide lassen sich mit Pipelines kombinieren, sodass einfache Maker-Deployments und anspruchsvolle CI/CD-Szenarien nebeneinander bestehen.
Gesunde ALM-Praktiken und typische Fehler
Die meisten ALM-Probleme entstehen aus wenigen wiederkehrenden Mustern. Die folgende Übersicht fasst die gesunden Praktiken den häufigen Fehlgriffen gegenüber.
| Bereich | Gesunde Praxis | Typischer Fehler |
|---|---|---|
| Solution-Typ | Unmanaged nur in Dev, managed in Test und Prod | Manuelle unmanaged Änderungen in der Produktion |
| Publisher | Ein Publisher, ein Präfix von Anfang an | Voreinstellung "new" oder mehrere Publisher parallel |
| Umgebungen | Getrennte Dev-, Test- und Prod-Umgebungen | Entwicklung direkt in der Produktion |
| Konfiguration | Werte über Environment Variables beim Import setzen | URLs und Keys hart in Flows und Apps kodiert |
| Abhängigkeiten | Eine Solution für alle Tabellen, keine Querbezüge | Gleiche Komponente in zwei Solutions |
| Rollout | Automatisiert über Pipelines mit Vorabvalidierung | Manueller Export-Import ohne Prüfung |
Ein zweites häufiges Muster betrifft die Geschäftslogik: Wer entscheidet, ob eine Regel als Business Rule, Plugin oder Cloud Flow umgesetzt wird, sollte die Wartbarkeit über den ganzen ALM-Zyklus mitdenken. Unser Leitfaden dazu, Business Rule, JavaScript, Plugin oder Cloud Flow, liefert die passende Entscheidungsmatrix.
Zusammengefasst: Ein einziger Publisher, sauber getrennte Umgebungen, entkoppelte Konfiguration und ein automatisierter Rollout über Pipelines bilden das Rückgrat eines skalierbaren Dynamics-365-Systems. Wenn Sie Ihr Solution-Modell aufsetzen oder ein gewachsenes ALM konsolidieren wollen, sprechen Sie uns an. Wir bewerten Ihre Umgebungslandschaft und bauen einen ALM-Prozess, der zu Ihrem Team passt.
Häufig gestellte Fragen
Was ist der Unterschied zwischen einer Managed und einer Unmanaged Solution in Dynamics 365?
Eine Unmanaged Solution ist der Arbeitsstand in der Entwicklungsumgebung, in dem Komponenten frei angelegt, geändert und gelöscht werden. Eine Managed Solution ist das geschlossene Auslieferungspaket, das in Test und Produktion importiert wird und dort nicht direkt editierbar ist. Best Practice ist, die managed Version durch Export der unmanaged als managed zu erzeugen und wie ein Build-Artefakt zu behandeln. In Nicht-Entwicklungsumgebungen sollte immer managed deployt werden.
Warum sollte ich nur einen Publisher und ein Präfix verwenden?
Der Solution Publisher besitzt die Komponenten einer Managed Solution, und diese Zuordnung lässt sich nachträglich nicht mehr ändern. Wird eine Tabelle über Publisher X managed ausgeliefert, kann sie später nicht einfach auf Publisher Y umgezogen werden. Der einzige Weg wäre Löschen und Neuanlegen, was den Verlust aller Daten in dieser Tabelle bedeutet. Ein einziger Publisher mit konsistentem Präfix hält das Modell sauber und vermeidet dieses Risiko.
Wozu brauche ich Environment Variables und Connection References?
Beide entkoppeln umgebungsabhängige Werte vom eigentlichen Inhalt der Solution. Environment Variables speichern Konfigurationswerte wie eine Ziel-URL, einen API-Key oder eine SharePoint-Site, die sich zwischen Dev, Test und Produktion unterscheiden. Connection References abstrahieren die konkrete Verbindung eines Konnektors. So bleibt dieselbe Solution über alle Umgebungen identisch, und nur die Werte werden beim Import gesetzt, ohne manuelle Nacharbeit an Apps oder Flows.
Was sind Power Platform Pipelines?
Power Platform Pipelines sind das eingebaute ALM-Werkzeug der Plattform. Sie erlauben es, Managed Solutions per Klick von einer Entwicklungsumgebung durch Test- bis in Produktionsstufen zu deployen, mit Vorabvalidierung von Abhängigkeiten, Verbindungen und Environment Variables. Das exportierte Solution-Artefakt durchläuft die Stufen unverändert und kann keine Stufe wie eine QA-Umgebung überspringen. Die beteiligten Zielumgebungen müssen Managed Environments sein.
Kann ich Dynamics 365 Solutions mit Git und Source Control verwalten?
Ja. Dataverse bietet eine native Git-Integration, mit der Entwicklungsumgebungen Solutions und Komponenten direkt mit einem Azure-DevOps-Git-Repository synchronisieren. Damit wird Source Control zur Quelle der Wahrheit, und Umgebungen lassen sich aus dem Repository neu aufbauen. Für 2026 ist zusätzlich GitHub als Git-Provider vorgesehen. Die Git-Integration ist für Entwicklungsumgebungen gedacht, während in Test und Produktion über Pipelines deployt wird.
Wie viele Umgebungen brauche ich für sauberes ALM?
Als Minimum gelten drei getrennte Umgebungen: Entwicklung, Test und Produktion. Entwicklung darf eine Developer-Umgebung sein, Test und Produktion sollten für automatisiertes ALM als Managed Environments laufen. Bei mehreren Teams oder modularer Architektur kommen dedizierte Entwicklungsumgebungen je Modul hinzu, aufgebaut auf einer gemeinsamen Basis-Solution. Direkt in der Produktion zu entwickeln gilt als Anti-Pattern.
Sie haben Fragen zu Dynamics 365?
Wir haben die Antworten.
Vereinbaren Sie einfach ein unverbindliches Erstgespräch mit einem Dynamics-Experten.
Termin vereinbaren
