ALM mit Azure DevOps
Lösungsarchitekten sind federführend bei der Definition des Prozesses, wie Änderungen von der Entwicklung bis zur Produktion gefördert werden. Diese Bemühung umfasst das Definieren der Anzahl von Phasen, wie z. B. Entwicklung > Test > Produktion und die Prozesse für die Höherstufung, unabhängig davon, ob sie manuell oder automatisiert erfolgt.
Microsoft erstellt Tools zur Unterstützung dieses Prozesses mit Microsoft Azure DevOps durch kontinuierliche Integration (CI) und kontinuierliche Bereitstellung (CD).
Dieser Abschnitt bietet einen Überblick über Azure DevOps und dazu, wie DevOps mit Microsoft Power Platform verwendet werden kann, um Bereitstellungen zu automatisieren.
Azure DevOps
Azure DevOps stellt Entwicklerservices für Supportteams bereit, um die Arbeit zu planen, bei der Codeentwicklung zusammenzuarbeiten und Anwendungen zu erstellen und bereitzustellen.
Azure DevOps enthält viele Funktionen zur Unterstützung der Entwicklung von Anwendungen:
- Azure Boards – Planen, verfolgen und diskutieren Sie die Arbeit in Ihren Teams.
- Azure-Pipelines – Verwenden Sie diese Option, um Builds und Versionen für die kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD) zu automatisieren.
- Azure Repos – Quellcodeverwaltung zum Speichern und Verfolgen von Änderungen.
- Azure Test Plans – Planen, Implementieren und Verfolgen von Skripttests.
- Azure Artifacts – Veröffentlichen Sie Lösungen, die von Buildpipeline erstellt werden.
Pipelines
Power Apps erstellt Tools zur Automatisierung der allgemeinen Build- und Bereitstellungsaufgaben, die sich auf Power Apps beziehen, mithilfe von Azure-Pipelines.
Buildpipelines können für folgende Aktionen verwendet werden:
- Entwicklungsumgebungen erstellen
- Commit für Änderungen von der Entwicklung zur Quellcodeverwaltung ausführen
- Das Tool zur Lösungsprüfung aktivieren
- Automatisierte Tests ausführen
- Ausgabelösungen aus der Quellcodeverwaltung (z. B. verwaltet oder nicht verwaltet) erstellen.
Releasepipelines können für folgende Aktionen verwendet werden:
- Lösungen aus Buildpipelines in einer oder mehreren Test- oder Produktionsumgebungen bereitstellen
- Automatisierte Tests im Rahmen des Freigabeprozesses durchführen
- Auf Genehmigungen warten, bevor mit der nächsten Umgebung fortgefahren wird
Aufgaben in Microsoft Power Platform Build Tools können zusammen mit allen anderen verfügbaren Azure DevOps-Aufgaben zum Erstellen Ihrer Build- und Releasepipelines verwendet werden. Zu den Pipelines, die Teams üblicherweise einrichten, gehören Initiieren, Exportieren von Dev, Build und Veröffentlichen.
Bereitstellungsmethoden
Beim Bereitstellen von Lösungen über eine Release-Pipeline muss entschieden werden, ob das Release manuell oder automatisch gepusht wird. Release-Pipeline-Ausführungen können manuell von einem Azure DevOps-Benutzer gestartet werden, automatisch nach einem Zeitplan ausgeführt oder durch eine Abrufanforderung ausgelöst. Kontinuierliche Bereitstellung kann in einer Release-Pipeline aktiviert werden, um die neueste Lösungsaufbau in andere Umgebungen zu übertragen, sobald der Build verfügbar ist.
Für sofortige Unterbrechungen/Korrekturen einer Lösung ist ein manueller Trigger wahrscheinlich die bevorzugte Methode, um den neuesten Build so schnell wie möglich in den vorgelagerten Umgebungen verfügbar zu machen, während ein geplanter oder Pull-Anforderungstrigger sinnvoller ist, wenn regelmäßig Updates an Lösungen durchgeführt werden.
Dazu ein Beispiel:
Contoso Bank hat ein Team von Entwicklern, die an einer komplexen Power Platform-Lösung arbeiten, die verschiedene Testphasen durchlaufen muss, bevor sie in Produktion geht. Das Entwicklungsteam verwendet agile Methoden für seine Entwicklungsprojekte und erzwingt ein regelmäßiges Muster von Build‑ und Release-Zyklen. Aus diesem Grund verwendet das Entwicklungsteam der Contoso Bank den Trigger für die geplante Releasepipeline, bei der der Zeitplan auf den vordefinierten Sprintzyklen basiert. Dies ist ein automatisierter Ansatz zum Pushen von Releases.
Wenn jedoch ein schwerwiegender Fehler in einer QAT-Umgebung entdeckt wird, können die Entwickler den Fehler mit einem neuen Build beheben und die Releasepipeline manuell auslösen, damit das Testen in der QAT-Umgebung so schnell wie möglich fortgesetzt werden kann.
Womöglich kann die Contoso Bank ein kleineres Projekt ohne strenge Zeitpläne für die Releasezyklen durchführen. In diesem Fall ist die Verwendung eines manuellen Triggers für die Releasepipeline möglicherweise vorzuziehen, da es keinen regelmäßigen Rhythmus gibt, wenn neue Builds bereitgestellt werden.
Weitere Informationen zur Verwendung von DevOps für den Wechsel von manuellem zu automatisiertem ALM sowie bewährten Methoden zur für Sie geeigneten Bereitstellungsmethode finden Sie unter DevOps für den Wechsel von manuellem zu automatisiertem ALM verwenden.
Alternative Automatisierungstools
Zur Automatisierung von Bereitstellungen ohne Verwendung von Azure DevOps gibt es folgende Alternativen:
- Dataverse- und Admin-APIs können verwendet werden, um über jede unterstützte Sprache zu automatisieren.
- PowerShell kann anstelle von Buildaufgaben verwendet werden, um mehr Kontrolle zu erhalten.
- Power Automate kann mit den Konnektoren für Plattformadministratoren verwendet werden, um Bereitstellungen zu automatisieren.
- GitHub-Aktionen werden derzeit in der Vorschau angezeigt.