Wichtige Überlegungen zu ALM

  • 8 Minuten

Lösungsarchitekten müssen die Strategie für das Application Lifecycle Management (ALM) im Projekt definieren. Diese Aufgabe ist Teil des Prozesses, der der Organisation hilft, eine ordnungsgemäße Governance für die Lösung zu etablieren.

Umgebungsstrategie

Eine Umgebungen ist ein Container, mit denen Sie Ihre Geschäftsdaten, Apps, Flows, Verbindungen und andere Anlagen speichern, verwalten und freigeben können, sowie die Berechtigungen, die Mitgliedern der Organisation die Verwendung der Ressourcen ermöglichen.

Eine Umgebung dient als Container zum Trennen von Apps, die über unterschiedliche Rollen, Sicherheitsanforderungen und Zielgruppen verfügen. Wie Sie sich entscheiden, Umgebungen zu verwenden, hängt z. B. von Ihrer Organisation und den Apps ab, die Sie erstellen möchten:

  • Sie können sich entscheiden, nur Apps in einer einzigen Umgebung zu erstellen.
  • Sie können separate Umgebungen erstellen, um die Test‑ und Produktionsversionen Ihrer Apps zu gruppieren.
  • Sie können separate Umgebungen erstellen, die bestimmten Teams oder Abteilungen in Ihrem Unternehmen entsprechen und jeweils die relevanten Daten und Apps für jede Zielgruppe enthalten.
  • Sie können separate Umgebungen für verschiedene Niederlassungen Ihres Unternehmens erstellen.

Um eine Umgebungsstrategie zu entwickeln, müssen Umgebungen und andere Ebenen der Datensicherheit so konfiguriert werden, dass die produktive Entwicklung in Ihrer Organisation unterstützt wird und gleichzeitig Ressourcen gesichert und organisiert werden. Eine Strategie zur Verwaltung der Umgebungsbereitstellung und des Umgebungszugriffs sowie zur Steuerung der darin enthaltenen Ressourcen ist wichtig für:

  • Daten und Zugriff sichern
  • Verstehen, wie die Standardumgebung richtig verwendet wird
  • Die richtige Anzahl von Umgebungen verwalten, um Ausbreitung zu vermeiden und Kapazität zu sparen
  • Application Lifecycle Management (ALM) vereinfachen
  • Ressourcen in logischen Partitionen organisieren
  • Vorgänge (und Helpdesk) bei der Identifizierung von Apps unterstützen, die sich in der Produktion befinden, indem sie in dedizierten Umgebungen verwendet werden
  • Sicherstellen, dass Daten in akzeptablen geografischen Regionen gespeichert und übertragen werden (aus Gründen der Leistung und Compliance)
  • Isolierung der zu entwickelnden Anwendungen sicherstellen

Diagramm mit einem Beispiel für eine Umgebungsstrategie

Die folgenden Umgebungstypen sind in Microsoft Power Platform verfügbar:

  • Sandbox – Eine Sandbox-Umgebung ist eine Nichtproduktionsumgebung von Dataverse. Eine von der Produktion isolierte Sandbox-Umgebung ist der Ort, um Anwendungsänderungen mit geringem Risiko sicher zu entwickeln und zu testen.
  • Produktion – Die Umgebung, in der Apps und andere Software für den beabsichtigten Gebrauch in Betrieb genommen werden
  • Community (Entwickler) – Der Power Apps-Community-Plan bietet einem Benutzer Zugriff auf Power Apps-Premium-Funktionen, Dataverse und Microsoft Power Automate nur für den individuellen Gebrauch. Diese Umgebung ist in erster Linie für Lernzwecke gedacht. Eine Entwicklerumgebung ist eine Einzelbenutzerumgebung und kann nicht zum Ausführen oder Freigeben von Apps verwendet werden. Eine Community-Planumgebung kann an der Azure DevOps-Pipeline teilnehmen.
  • Standard – Für jeden Mandanten wird automatisch eine einzige Standardumgebung erstellt, die von allen Benutzern in diesem Mandanten gemeinsam genutzt wird. Die Standardumgebung wird von Microsoft 365-Diensten verwendet.
  • Testversion – Testumgebungen dienen zum Ausprobieren neuer Funktionen oder zum Durchführen von Machbarkeitskonzepten. Testumgebungen werden nach 30 Tagen automatisch gelöscht.

Wichtig

Der Lösungsarchitekt muss definieren, wie viele Umgebungen erforderlich sind, welche Zwecke sie erfüllen und welche Abhängigkeiten zwischen den Umgebungen bestehen. Zu einer guten ALM-Methode sollte mindestens die Verwendung einer Testumgebung gehören, bevor etwas in der Produktionsumgebung bereitgestellt wird. Diese Methode stellt sicher, dass Sie einen Ort zum Testen Ihrer App haben, sorgt jedoch auch dafür, dass die Bereitstellung getestet werden kann.

Weitere Informationen erhalten Sie unter Umgebungen und Umgebungsstrategie.

Lösungen und andere nicht lösungsorientierte Codes und Komponenten verarbeiten

Microsoft Power Platform-Projekte bestehen aus Komponenten, die in Lösungen in Umgebungen paketiert werden können, und Komponenten, die nicht zu Lösungen hinzugefügt werden können, z. B. in Azure bereitgestellte Komponenten, Konfigurationsdaten und Power BI-Berichte. Der ALM-Plan muss berücksichtigen, wie mit diesen nicht lösungsorientierten Komponenten umgegangen werden soll.

Der Lösungsarchitekt muss entscheiden, ob das Application Lifecycle Management mithilfe von Lösungen oder mithilfe der Herkunftscodeverwaltung verwaltet wird. Herkömmlich waren Microsoft Power Platform-Projekte eher umgebungsorientiert, aber viele tendieren jetzt dazu, sich auf die Herkunftscodeverwaltung zu konzentrieren.

Wenn Sie einen umgebungsorientierten Ansatz verwenden, gilt Folgendes:

  • Die Entwicklungsumgebung ist die Masterkopie aller Änderungen.
  • Änderungen werden direkt von dev > test > production gefördert.

Wenn Sie einen Ansatz verwenden, der sich am Herkunftscode orientiert, gilt Folgendes:

  • Die Herkunftscodeverwaltung ist der Master.
  • Die Entwicklungsumgebung wird aus der Herkunftscodeverwaltung neu erstellt (dieser Prozess kann automatisiert und wiederholbar sein).
  • Änderungen aus der Entwicklungsumgebung werden in die Herkunftscodeverwaltung eingecheckt.

Diagramm mit einem Ansatz, der sich am Herkunftscode orientiert

Ein auf den Herkunftscode ausgerichteter Ansatz ermutigt Sie, einen endgültigen Master zu haben und Entwicklungsumgebungen für jede nachverfolgte Version neu erstellen zu können. Derzeit fördert und entwickelt Microsoft Tools zur Unterstützung von ALM mit Herkunftscodeverwaltung.

Hinweis

Idealerweise sollten alle Umgebungen außer der Produktion verworfen werden können. Mit anderen Worten: Die Entwicklungs- und Testumgebungen können gelöscht und ohne Verlust neu erstellt werden.

Die Verwendung eines auf die Herkunftscodeverwaltung ausgerichteten Ansatzes ermöglicht einen Azure DevOps-Ansatz mit Build- und Release-Pipelines. Wenn Sie einen umgebungsorientierten Ansatz verwenden, müssen Sie den Workflow für App-Hersteller und -Entwickler definieren. Der Lösungsarchitekt muss definieren, wie und wer die App in den Umgebungen von der Entwicklung bis zur Produktion bewirbt.

Der Lösungsarchitekt muss außerdem definieren, wie jede Umgebung konfiguriert werden soll, und nach Möglichkeiten suchen, dies zu vereinfachen.

Teamarbeit

Im Vergleich zur herkömmlichen App-Entwicklung unterscheiden sich Microsoft Power Apps-Projekte in zwei wichtigen Bereichen:

  • Wie verschiedene Mitglieder des Projektteams zusammenarbeiten, um die Lösung zu erstellen
  • Entwicklungsmethodik

Power Apps ist eine Plattform, die professionellen Entwicklern und Citizen Developer zugute kommt. In einer traditionellen Entwicklungsumgebung konnten nur professionelle Entwickler an der eigentlichen Erstellung einer App beteiligt sein. Mit Power Apps kann jeder die Apps erstellen, die er benötigt, indem er erweiterte Funktionen verwendet, die bisher nur professionellen Entwicklern zur Verfügung standen. Power Apps „demokratisiert“ die Entwicklung benutzerdefinierter Geschäftsanwendungen, da Benutzer funktionsreiche benutzerdefinierte Geschäftsanwendungen erstellen können, ohne Code schreiben zu müssen.

Diagramm, das das sich entwickelnde Ökosystem anzeigt

Mit Power Apps können Sie schnell eine verwendbare Version Ihrer App erstellen, da Power Apps eine WYSIWYG-Entwicklungserfahrung bietet. Sie können die tatsächlich funktionierende App früh im Entwicklungsprozess kennenlernen. Wenn neue Anforderungen auftreten, können Sie der nächsten Version neue Funktionen hinzufügen.

Diagramm des Power Apps-Entwicklungsansatzes

Probleme beim Anpassen und Entwickeln von Komponenten in Microsoft Power Platform umfassen:

  • Microsoft Power Platform unterstützt keine Versionierung von Komponenten (außer für Canvas-Apps).
  • Benutzer können nicht an derselben Microsoft Power Platform-Komponente gleichzeitig arbeiten.
  • Modellgesteuerte Apps bestehen aus mehreren Komponenten mit jeweils eigenen Editoren, sodass die Arbeit zwischen den Herstellern aufgeteilt werden kann. Umgekehrt haben Canvas-Apps nur einen Editor und es kann immer nur eine Person gleichzeitig an einer App arbeiten. Durch die Verwendung von Canvas-Komponenten können Sie mehreren Herstellern ermöglichen, gleichzeitig an derselben App zu arbeiten.

Lösungsarchitekten sollten den Workflow festlegen, wie App Builder Änderungen vornehmen und diese fördern. Proaktive Kommunikation und Arbeitsaufträge sollten verwaltet werden, um Konflikte zwischen Entscheidungsträgern zu minimieren.

Sie können Konflikte zwischen Herstellern minimieren, indem Sie für jeden Hersteller eine individuelle Umgebung erstellen. Einzelne Herstellerumgebungen bieten Isolation und Nachverfolgung, erfordern jedoch zusätzlichen Aufwand, um die Arbeit zusammenzuführen und Konflikte zu lösen. Eine gemeinsam genutzte Entwicklerumgebung kann weniger komplex sein, bietet jedoch keine Isolation zwischen App-Builder, und es fehlen Details bei der Verfolgung von Änderungen.

Herkunftscodeverwaltung

Obwohl Sie einen umgebungsorientierten Ansatz verwenden, müssen Sie dennoch entscheiden, wo sich die Masterkopie der Lösungen und des Codes befindet.

Lösungsorientierte Entwicklercode-Anlagen (wie Plug-Ins, PCF-Codekomponenten und Formularskripte (aus TypeScript transpiliert)) sollten auf einer Build-Umgebung und nicht auf dem Desktop des Entwicklers „erstellt“ werden. Nach der Erstellung sollten die Assets in einer Umgebung bereitgestellt werden, aus der die Master-Lösung exportiert oder in eine zu installierende Lösung integriert wird.

Tools

Microsoft bietet verschiedene Tools und Apps, die Sie mit ALM in Microsoft Power Platform verwenden können:

  • Microsoft Power Platform Admin Center – Bietet Administratoren ein einheitliches Portal zum Erstellen und Verwalten von Umgebungen
  • Power Apps-Erstellungstools Automatisierung der allgemeinen Build- und Bereitstellungsaufgaben, die sich auf Power Apps beziehen, mithilfe von Azure DevOps.
  • GitHub – Beliebtes Beispiel für ein Versionskontrollsystem
  • Konfigurationsmigrationstool – Ermöglicht das Verschieben von Konfigurations- und/oder Referenzdaten in verschiedenen Umgebungen
  • Package Deployer – Ermöglicht die Bereitstellung von Assets-Paketen für Dataverse-Instanzen Pakete können aus Lösungsdateien und Flatfiles, benutzerdefiniertem Code, HTML-Dateien und Daten bestehen.
  • Solution Packager – Ein Tool, das eine komprimierte Lösungsdatei in mehrere XML-Dateien und andere Dateien entpackt, damit sie einfach von einem Herkunftscodeverwaltungssystem verwaltet werden können.
  • Microsoft Power Apps-CLI – Ein einfache Befehlszeilenschnittstelle, mit der Entwickler Codekomponenten erstellen möchten.
  • PowerShell-Modul für die Paketbereitstellung – Wird verwendet, um der Dataverse-Umgebung Pakete bereitzustellen
  • PowerShell-Modul für Power Apps-Prüfung – Interagiert mit dem Power Apps-Überprüfungsdienst, damit Sie statische Analysejobs ausführen und die Ergebnisse herunterladen können.

Hinweis

GitHub-Aktionen für Microsoft Power Platform werden derzeit in der Vorschau angezeigt.