Application Lifecycle Management definieren
Die meisten Projekte haben einen vollständigen Plan für die Qualitätssicherung und ein Team. Alle Mitglieder des Entwicklerteams müssen jedoch auf gewisse Art und Weise mitwirken, damit qualitativ hochwertige Lösungen gewährleistet werden. Es gibt viele Teile eines Projekts, auf die Sie Einfluss haben und die zum Erfolg führen können, vom Komponententest bis zur Konfiguration zur Unterstützung bei Release-Pipelines mit Azure DevOps.
Application Lifecycle Management (ALM)
In der Regel ist der Lösungsarchitekt oder eine technische Fachkraft für DevOps Eigentümer des ALM-Prozesses. Aber da Sie ein wichtiges Mitglied des Entwicklerteams sind, ist Ihr Engagement unter deren Leitung erforderlich. Sie müssen die ALM-Prozesse verstehen und so befolgen, wie sie vom Lösungsarchitekten (oder Entwicklungsingenieur) festgelegt wurden, um erfolgreich zu sein. Stellen Sie Fragen, bieten Sie an, den Plan zu dokumentieren, und lassen Sie sich Ihre Kenntnisse bestätigen. Sie erfahren beim Erstellen dieser Dokumentation zudem mehr über die ALM-Pläne für das Projekt.
Während der Entwicklung validieren Sie Ihre Arbeit mit Plattform-Tools wie der App-Überprüfung, dem Flow-Checker und der Lösungsprüfung.
Ihre gesamte Arbeit wird im Kontext einer Lösung erbracht, und Sie sollten wissen, wie Sie Lösungen gemäß den Anweisungen des Lösungsarchitekten erstellen, exportieren und importieren. Bei einem größeren Projekt gibt es wahrscheinlich formalisiertere Buildpipelines und automatisierte kontinuierliche Bereitstellung.
Solution Packager
Der Solution Packager sollte verwendet werden, um die nicht verwaltete Lösung aus der Entwicklung zu nehmen und für die Speicherung in einem Quellcodeverwaltungs-Repository vorzubereiten. Der Solution Packager nimmt die einzelne Lösungsdatei und zerlegt sie in einzelne Dateien, die jede Lösungskomponente darstellen. Der Solution Packager wird als Entpacken der Lösung bezeichnet. Die Ausgabe vom Solution Packager wird dann in das Quellcodeverwaltungs-Repository eingefügt. Die Ausgabeversion stellt nun die vertrauenswürdige Quelle für das Projekt dar.
Der Solution Packager kann den Ordner auch aus der Quellcodeverwaltung entpacken und die einzelne Lösungsdatei neu erstellen. Mit den in die Quellcodeverwaltung eingefügten Dateien werden die Lösungen erstellt, die in die anderen Umgebungen importiert werden. Während Solution Packager manuell ausgeführt werden kann, wird es häufiger mit Microsoft Power Platform Build Tools als Teil einer automatisierten Pipeline ausgeführt.
Package Deployer
Mit dem Package Deployer können Sie ein Paket erstellen, das mehrere Lösungen, Daten aus dem Konfigurationsmigrationstool und Entwicklercodelogik enthält, die vor und nach Abschluss des Imports des Pakets ausgeführt werden. In vielerlei Hinsicht können Sie sich Package Deployer als Installationsassistenten für Microsoft Power Platform vorstellen. Der Package Deployer kann interaktiv ausgeführt werden, um Pakete und Daten manuell in eine Umgebung zu importieren. Der Package Deployer unterstützt auch die Ausführung mit PowerShell, wodurch die Automatisierung und Integration in Azure Pipelines ermöglicht wird.
Lösungsprüfung
Da Power Automate und Power Apps zum Anpassen einer Bereitstellung verwendet werden, bietet jede Anwendung ihre eigene Inline-App-Prüfung, die für die Lösung von Problemen in Echtzeit hilfreich sind. Die Lösungsprüfung (weitere Informationen dazu hier) kann jedoch die gesamte Lösung anzeigen, statische Analysen durchführen und eine detaillierte Liste aller gefundenen Probleme erstellen.
Die Lösungsprüfung sollte regelmäßig für alle nicht verwalteten Lösungen ausgeführt werden, die Sie in Ihren Entwicklungsumgebungen erstellen. Die Lösungsprüfung kann Power Apps- und Power Automate-Flows sowie Code-Assets wie Plug-Ins analysieren, die Entwickler erstellen. Das Projektteam kann die Lösungsprüfung manuell über das Herstellerportal ausführen, indem es die Lösung auswählt und dann die Prüfung ausführt. Die Lösungsprüfung kann auch automatisiert werden, um als Teil eines Erstellungsprozesses entweder mit PowerShell oder mit Azure Pipeline-Aufgaben ausgeführt zu werden. Durch die Automatisierung der Lösungsprüfung kann es ein integraler Bestandteil des Erstellungsprozesses werden und sogar so eingerichtet werden, dass das Erstellen gestoppt wird, wenn zu viele Fehler aufgetreten sind. Das einfache Ausführen der Lösungsprüfung reicht nicht aus, um erfolgreich zu sein. Außerdem muss ein Plan vorhanden sein, um festgestellte Probleme regelmäßig zu bewerten und zu lösen.
Bereitstellung automatisieren
Ein Bereich, der im Rahmen des Erstellungsplans genauso wichtig ist, ist die Frage, mit welcher Automatisierung der Prozess wiederholbar gemacht werden kann. Es gibt zahlreiche Tools von Microsoft und der Community, die zur Automatisierung des Erstellungsprozesses verwendet werden können. Microsoft investiert in Azure DevOps und in eine Reihe von Microsoft Power Platform-Aufgaben, mit denen die Aufgaben des Lösungsmanagements und der Bereitstellung automatisiert werden können. Zum Beispiel könnte ein Team eine Azure Pipeline haben, die jeden Tag um 19:00 Uhr aus der Entwicklung extrahiert und in ein Git-Repository eingefügt wird. Dieselbe Pipeline kann auch zum Ausführen der Lösungsprüfung verwendet werden. Wenn das Team morgens zur Arbeit kommt, weiß es sofort, ob im Build der vorherigen Nacht Probleme festgestellt wurden. Die Pipeline könnte die Lösung auch in eine fehlerfreie Build-Umgebung importieren, die es ermöglicht, Abhängigkeiten zu erkennen, die während der Entwicklung dieses Tages unbeabsichtigt eingeführt wurden. Dadurch wird sichergestellt, dass in der Quellcodeverwaltung eine fehlerfreie Version eingefügt wird, die für die Bereitstellung in anderen Umgebungen bereit ist. Pipelines können auch zur Automatisierung von Tests verwendet werden, sodass dies nur ein weiterer Schritt innerhalb der Pipeline ist. Azure Pipelines werden auch zum Erstellen des verwalteten Lösungsartefakts verwendet, das in den Releasepipelines für die Bereitstellung in vorgelagerten Umgebungen wie Test und Produktion verwendet wird. Das gleiche Lösungsartefakt, das im Test verwendet wurde, wird bis zur Produktion verwendet. Dies stellt sicher, dass keine neuen überraschenden Änderungen eingeführt werden, während die Höherstufung durch die Reihe von Umgebungen verläuft, die bei der Produktion enden. Azure Pipelines kann auch zum Erstellen von Entwicklercode-Assets verwendet werden, um sicherzustellen, dass sie nicht auf einer lokalen Entwickler-Workstation erstellt werden.
Versionskontrolle
Wenn Änderungen von der Entwicklung über den Test bis zur Produktion vorgenommen werden, handelt es sich standardmäßig um einen einzelnen Arbeitsstream von Änderungen. Wenn ein Problem in der Produktion festgestellt wird, beheben Sie es in der Entwicklung und stufen es dann durch die Reihe von Umgebungen zurück in die Produktion hoch. Ein einzelner Arbeitsstream wie dieser funktioniert gut, wenn keine neue Entwicklung durchgeführt wird. Wenn das Entwicklungsteam in seiner Entwicklungsumgebung bereits zu Version zwei übergegangen ist und dann einen Fehler behebt, der in der Produktion festgestellt wurde, während die Fehlerbehebung in die Produktion verschoben wird, findet auch die laufende Arbeit für Version zwei statt, da dies alles kombiniert war. Die ideale Aktion besteht darin, dass die Änderung in einer separaten Arbeitsstream-Entwicklungsumgebung vorgenommen wird, die nur das darstellt, was bereits in Produktion war, und dass das, was höhergestuft wurde, nur die Fehlerbehebung und nichts aus Version zwei enthielt. Dies erfordert, dass das Projektteam im Voraus plant und eine Strategie für die Verwaltung mehrerer aktiver Versionen hat. Dies kann so einfach sein wie ein aktiver Entwicklungsstream und ein Wartungsstream zur Unterstützung der Produktion. Bei komplexeren Projekten können sogar mehrere aktive Entwicklungsstreams gleichzeitig ausgeführt werden.
Die gleichzeitige Behandlung von aktiven Entwicklungs- und Wartungsstreams erfolgt normalerweise über eine Kombination von Dataverse-Umgebungen und Quellcodeverwaltungszweigen. Verzweigungen ermöglichen eine Kopie der Projektressourcen und eine isolierte Methode zum Vornehmen von Änderungen in einer Umgebung, die dieser Verzweigung zugeordnet ist. Änderungen von einer Verzweigung können mit einer anderen Verzweigung zusammengeführt werden. Die Verzweigungsstrategie sollte so einfach wie möglich gehalten werden, um zu vermeiden, dass beim Zusammenführen von Verzweigungen viele Konflikte gelöst werden müssen.