Umgebungsstrategie für ALM
Um den Prinzipien des Application Lifecycle Management (ALM) zu folgen, benötigen Sie separate Umgebungen für die Entwicklung und Produktion von Apps. Obwohl Sie das Basis-ALM nur mit getrennten Entwicklungs- und Produktionsumgebungen durchführen können, empfehlen wir, dass Sie auch mindestens eine Testumgebung pflegen, die von Ihren Entwicklungs- und Produktionsumgebungen getrennt ist. Wenn Sie über eine separate Testumgebung verfügen, können Sie eine End-to-End-Validierung durchführen, die Lösungsbereitstellung und Anwendungstests umfasst. Einige Organisationen benötigen möglicherweise auch mehr Umgebungen für Benutzerakzeptanztests (UAT), Systemintegrationstests (SIT) und Schulungen.
Getrennte Entwicklungsumgebungen können hilfreich sein, um Änderungen von einem Arbeitsaufwand zu isolieren, der eingecheckt wird, bevor er abgeschlossen ist. Getrennte Entwicklungsumgebungen können auch hilfreich sein, um Situationen zu reduzieren, in denen eine Person eine andere Person negativ beeinflusst, während sie Änderungen vornimmt.
Jede Organisation ist einzigartig, daher sollten Sie sorgfältig prüfen, welche Anforderungen Ihre Umgebung an Ihre Organisation stellt.
Entwicklungs-Umgebungen
Sie sollten Fragen beantworten wie z.B:
- Wie viele Entwicklungsumgebungen benötige ich?
- Weitere Informationen: Umgebungsübersicht
- Wie kann ich Umgebungen automatisch aus dem Quellcode bereitstellen?
- Weitere Informationen: Microsoft Power Platform Build Tools für Azure DevOps
- Was sind die Abhängigkeiten von meiner Umgebung?
- Mehr Informationen: Schichten mehrerer Lösungen und Abhängigkeiten
Andere Umgebungen
Sie sollten auch die Frage beantworten: „Welche Arten von Nicht-Entwicklungsumgebungen brauche ich?
Zusätzlich zu Ihrer Produktionsumgebung benötigen Sie z.B. möglicherweise separate Test-, UAT-, SIT- und Vorproduktionsumgebungen. Beachten Sie, dass jede gesunde ALM-Praxis mindestens die Verwendung einer Testumgebung umfassen sollte, bevor etwas in der Produktionsumgebung bereitgestellt wird. Dadurch wird sichergestellt, dass Sie einen Ort haben, an dem Sie Ihre Apps testen können, aber es wird auch sichergestellt, dass der Einsatz selbst getestet werden kann.
Weitere Informationen: Erstellung einer Umgebungsstrategie für Microsoft Power Platform
Multi-geografische Überlegungen
Power Platform-Umgebungen folgen einem bestimmten Zeitplan für Dienstaktualisierungen, da Umgebungen auf der ganzen Welt aktualisiert werden. Insgesamt gibt es sechs Stationen, die in erster Linie durch die geografische Lage definiert werden. Service-Updates werden nacheinander für jede Station angewendet. Die Dienstaktualisierungen von Station 2 werden also vor Station 3 angewendet. Daher ist es üblich, dass Umgebungen, die sich in verschiedenen Stationen befinden, zu einem bestimmten Zeitpunkt unterschiedliche Versionen haben. Weitere Informationen zum Aktualisierungszeitplan für Umgebungsdienste finden Sie unter Veröffentlichte Versionen von Microsoft Dataverse
Lösungsimport und Umgebungsversion
Wenn Sie über mehrere Umgebungen in verschiedenen Regionen verfügen, ist es wichtig, beim Importieren einer Lösung Folgendes zu verstehen:
- Sie können eine Lösung in eine Umgebung importieren, die eine neuere Version als die Umgebung ist, in die die Lösung exportiert wurde.
- Sie können eine Lösung nicht zuverlässig in eine Umgebung importieren, die eine ältere Version als die Umgebung ist, in die die Lösung exportiert wurde. Dies liegt daran, dass in der älteren Umgebung möglicherweise Komponenten oder erforderliche Funktionen fehlen.
Beispiel für die erfolgreiche Ausrichtung von Umgebungen mit Service-Update-Stationen
Stellen Sie sich vor, Sie haben Produktionsumgebungen in Kanada und den USA. In diesem Fall sollten sich Ihre Entwicklungsumgebungen in Nordamerika (Station 5) und nicht in Kanada (Station 2) befinden. Dann sind Ihre Entwicklungsumgebungen immer dieselbe oder eine frühere Version als Ihre Produktionsumgebungen, wodurch Konflikte mit Lösungsimportversionen verringert werden.
