MAUI Blazor Lösungsstruktur und Flexibilität der CI-Pipeline

MAUI-Apps sind großartig, aber langsam in der Entwicklung

MAUI Blazor Hybrid-Apps sind großartig. Mit MAUI können Sie ganz einfach mehrere Plattformen (Android, iOS, Mac und Windows) ansprechen. Blazor bietet Ihnen ein hochproduktives Framework für die Entwicklung der Benutzeroberfläche für diese Zielplattformen. Und wir können die Vorzüge von C# und .NET nutzen. Aber MAUI-Anwendungen sind langsam zu erstellen. Jede Zielplattform erfordert einen separaten Build. Und jeder dieser Builds braucht Zeit und verursacht Kosten. Bei GitHub Actions sind die Minuten für Windows-Runner beispielsweise 2x so lang wie für Linux. Mac-Läufer benötigen 10x mehr. Siehe hier.

Der typische MAUI-App CI-Workflow ist zu langsam

In einem typischen MAUI-App-CI-Workflow könnten wir die folgenden Schritte für jede Zielplattform durchlaufen.

1. AUI-App für eine bestimmte Plattform erstellen
2. Test erstellte App

Die lange Build-Zeit für jede Plattform bedeutet, dass wir lange warten müssen, bevor wir wissen, ob unser Build erfolgreich war und unsere Tests alle bestanden haben. Es bedeutet auch, dass jeder Durchlauf des CI-Workflows relativ teuer ist. Wenn wir beschließen, dass die Erstellung für jede Zielplattform bei jedem Push zu teuer ist. Dann müssen wir nach mehr Flexibilität in unseren Arbeitsabläufen suchen.

Wenn sich der gesamte Code im MAUI-Anwendungsprojekt befindet, haben wir nicht viel Flexibilität bei der Erstellung und Prüfung. Wir möchten in der Lage sein, den Großteil unseres Anwendungscodes schnell und kostengünstig zu erstellen und zu testen und schnelleres Feedback in unserem CI-Workflow zu erhalten. Wir möchten auch die Freiheit haben, selbst zu entscheiden, wann und wie oft die teuren plattformspezifischen MAUI-Anwendungs-Builds durchgeführt werden.

Verschieben Sie Code aus dem MAUI-App-Projekt

Eine Änderung der Visual Studio-Lösung und der Projektstruktur kann eine bessere Flexibilität des CI-Workflows und eine bessere Kostenkontrolle ermöglichen. Der Trick besteht darin, den Großteil des Codes aus dem MAUI-App-Projekt in separate Bibliotheksprojekte zu verschieben.

Hier sehen Sie ein Beispiel für die Struktur einer Visual Studio-Lösung.

• Visual Studio Lösung
  • MAUI-App
  • MAUI-App-Tests
  • Blazor UI (Razor-Klassenbibliothek)
  • Blazor UI-Tests
  • Klassenbibliothek 1
  • Klassenbibliothek 1 Tests
  • Klassenbibliothek 2
  • Klassenbibliothek 2 Tests

Der Großteil des Codes, einschließlich des Codes für die Blazor-Benutzeroberfläche, sollte aus dem MAUI-Blazor-Hybrid-App-Projekt ausgelagert werden. Und in separate Klassenbibliotheksprojekte. Eine Lösungsstruktur wie diese ermöglicht es uns, die Bibliotheksprojekte separat zu erstellen und zu testen. Ohne das MAUI-App-Projekt zu erstellen.

In einem späteren Blog-Beitrag beschreibe ich die Schritte zum Verschieben von Blazor UI-Code aus einem MAUI Blazor Hybrid-App-Projekt in ein separates Razor-Klassenbibliothek-Projekt.

Nutzen Sie die Flexibilität in unseren Arbeitsabläufen

Mit der neuen Lösungsstruktur können wir unseren CI-Workflow auslösen, um unsere Klassenbibliotheksprojekte zu erstellen und zu testen, wenn Codeänderungen vorgenommen werden. So erhalten wir schnelles und kostengünstiges Feedback.

Wir können entscheiden, wann und wie oft die zeitintensiven und relativ teuren plattformspezifischen MAUI-Anwendungs-Workflows durchgeführt werden. Zum Beispiel können wir die Erstellung und den Test der MAUI-Anwendung für jede Plattform erst dann auslösen, wenn ein Pull Request genehmigt wurde. Oder wir möchten den Workflow für die MAUI-Anwendung für eine bestimmte Plattform erst dann auslösen, wenn ein bestimmtes Prozess-Gate für diese Plattform freigegeben wurde.

Wir haben jetzt viel Flexibilität bei der Anpassung unserer MAUI Blazor Hybrid-App-Workflows an unsere Geschäfts- und Entwicklungsanforderungen.

Arbeitsablauf zum Erstellen und Testen der Bibliotheken

Um diese Flexibilität zu nutzen, benötigen wir eine einfach zu wartende Technik, die wir in unseren CI-Workflows verwenden können, um die Bibliotheken in der Lösung zu erstellen und zu testen, ohne die MAUI-App zu erstellen.

Wenn Sie die Visual Studio-Lösung mit den Befehlen dotnet build oder dotnet test erstellen, werden alle Projekte in der Lösung erstellt, einschließlich der MAUI-App. Wir brauchen also eine Technik, die die MAUI-Anwendung nicht mitbaut.

Wir könnten eine separate VS-Lösung erstellen, die das MAUI-App-Projekt nicht enthält. Oder wir könnten unseren Arbeitsablauf so einrichten, dass die einzelnen Projekte zum Erstellen und Testen angegeben werden. Aber solche Techniken erfordern zusätzlichen Aufwand bei der Pflege, wenn Projekte hinzugefügt oder entfernt werden, während sich die Lösung weiterentwickelt. Wenn wir z.B. vergessen zu aktualisieren, wenn ein Projekt hinzugefügt wird, erhalten wir wahrscheinlich keine Benachrichtigung, die uns daran erinnert, und neue Tests werden möglicherweise übersprungen. Wir brauchen eine Technik, die weniger fehleranfällig ist.

Wie wäre es, wenn der Workflow das MAUI-App-Projekt aus der Lösung entfernen würde? Im Workflow zum Erstellen und Testen der Bibliothek können wir das MAUI-App-Projekt aus der Lösung entfernen, so dass es ignoriert wird. Diese Technik funktioniert gut und hat keine Auswirkungen auf die separaten Arbeitsabläufe, die die MAUI-App für jede Plattform erstellen und veröffentlichen (da diese ohnehin immer das spezifische Projekt angeben müssen).

Hier sehen Sie ein Beispiel für einen Auftrag in einem GitHub-Workflow zum Erstellen und Testen aller Projekte der Klassenbibliothek in der Lösung. Dabei wird die MAUI-App aus der Lösung entfernt.

Schlussfolgerungen

Ich habe beschrieben, wie wir Flexibilität, schnelles Feedback und eine bessere Kostenkontrolle in unseren CI-Pipelines erreichen können. Indem wir ändern, wie unsere Visual Studio-Lösung und unser Projekt organisiert sind. Diese Umstrukturierung beinhaltet die Aufteilung von Projekten für Code, dessen Erstellung zeitaufwendig oder teuer ist. Ich habe auch eine einfache und leicht zu pflegende Technik für Build- und Test-Workflows beschrieben. So können bestimmte Projekte in einer Lösung von einer Pipeline ausgeschlossen werden. Dieser Beitrag konzentrierte sich auf MAUI Blazor Hybrid-Anwendungen. Die Konzepte können jedoch auf Visual Studio-Lösungen für jede Art von Anwendungen angewendet werden.