12. Aug 2024
Lesedauer 14 Min.
CI/CD-Pipeline in der Cloud
Azure Development Mobile Enterprise Architecture
Das Bereitstellen und Veröffentlichen mobiler Anwendungen muss keine Unwägbarkeit sein: So kann es zum Beispiel mit Azure Pipelines und Azure DevOps Services gelingen.

F ür den Anwender ist es in der heutigen Zeit selbstverständlich, mit einem Smartphone auf benötigte Unternehmensdaten etwa aus dem Enterprise Resource Planning oder dem Customer Relationship Management zuzugreifen.Die Automatisierung von Arbeitsabläufen und die Steigerung der Effizienz sind nur zwei der Vorteile einer erfolgreichen Entwicklung mobiler Unternehmensanwendungen.Allerdings stellt man dabei als Entwickler sehr schnell fest, dass die Entwicklung einer mobilen Enterprise-App manchmal doch eine Herausforderung sein kann. Im Vorfeld gilt es eine Vielzahl von Aspekten wie etwa die Sicherheit, den API-Zugriff (Konzept), das Design für Mobilgeräte und die Nutzung von Cloud- und Microservices zu beachten. Zudem haben das Testen, die Build-Automatisierung und die Integration einer App in die Systeminfrastruktur ihre Eigenheiten.Es ist also für Sie als Entwickler unverzichtbar, sich mit einer API-Strategie beziehungsweise dem API-Design zu beschäftigen. Da das API in den meisten Fällen in Geschäftsfunktionen integriert ist, sollte es auch hohen Sicherheitsstandards genügen.Auch die Integration mit vorhandenen Backend-Ressourcen gilt es zu beachten. Oft stehen nur veraltete Backend-Dienste zur Verfügung, was die Entwicklungsgeschwindigkeit bremst und Probleme verursacht. In manchen Fällen ist es nicht einmal möglich, eine mobile App in den Dienst zu integrieren. Dann sind alternative Strategien erforderlich.Die Sicherheit hat bei einer mobilen Anwendung ebenfalls eine entsprechend hohe Priorität. Die App sollte so sicher wie möglich sein, angefangen bei der sicheren Speicherung von Benutzerdaten bis hin zur Reduzierung von Schwachstellen im System auf ein Minimum. Die Anwender müssen in der Lage sein, Daten sicher zu übertragen, ohne Unternehmensdaten zu gefährden.Die von Microsoft zur Verfügung gestellte Azure-Pipelines-Plattform kann Sie bei der effektiven Erstellung von Android-, iOS- und .NET-MAUI-Apps unterstützen, die Ihre geschäftlichen Unternehmensanforderungen erfüllen. Des Weiteren können Sie Azure auch verwenden, um intelligente Backend-Dienste für Ihre Apps bereitzustellen und den Entwicklungszyklus zu automatisieren.
Visual Studio App Center
Warum eigentlich nicht für die Entwicklung das Visual Studio App Center verwenden? Auch dieser Azure-Mobile-App-Service vereint eine Vielzahl von Diensten in einer DevOps-Cloud-Lösung.Um die Plattform ist es in letzter Zeit aber sehr ruhig geworden. Microsoft hat jetzt für das App Center das Support-Ende mitgeteilt: Das Visual Studio App Center wird voraussichtlich am 31. März 2025 außer Betrieb genommen. Microsoft selbst empfiehlt, die Builds von App Center zu Azure Pipelines zu migrieren oder von Anfang an auf die DevOps-Services von Azure Pipelines zu setzen.App-Entwicklung für mobile Geräte
Für die App-Entwicklung für mobile Geräte und für die Backend-Infrastruktur setzt Microsoft auf zahlreiche unterschiedliche Dienste (Services), die sich hinter der Azure-Pipelines-Plattform verbergen.Azure Pipelines umfasst alle Funktionen der Entwicklung als vollständig verwaltete Plattform, die hoch skalierbar und universell zugänglich ist. Das heißt, Azure Pipelines definiert Azure-DevOps-Services als Platform as a Service (PaaS) im Cloud-Computing-Modell, das es einfacher macht, ein skalierbares Cloud-Backend mit Ihren Client- und mobilen Anwendungen zu verknüpfen, um mobile Apps zu erstellen.Azure Pipelines
Azure Pipelines stellt eine Automatisierungs-Pipeline dar, um Code basierend auf neuem Code oder Codeänderungen bereitzustellen. Hierbei werden die Codeprojekte automatisch erstellt und getestet. Der Automatisierungsprozess kombiniert Continuous Integration (CI), Continuous Delivery (CD) und Continuous Testing, sodass Code kompiliert, getestet und an einem beliebigen Ziel, zum Beispiel im Google Play Store, bereitgestellt werden kann.Continuous Integration [1] ist ein Verfahren, das von Entwicklungsteams zum Automatisieren, Mergen und Testen von Code verwendet wird und bei dem die Entwickler alle Codeänderungen regelmäßig in einem zentralen Repository zusammenführen. Diese Änderungen werden dann als Teil des CI-Prozesses automatisiert erstellt und getestet.Continuous Delivery [2] ist eine Softwareentwicklungsmethode, mit der Code kompiliert, getestet und in einer oder mehreren Test- oder Produktivumgebungen bereitgestellt wird. Durch diese automatisierten Prozesse können kontinuierlich neue Versionen ausgeliefert und Fixes für bestehende Systeme ausgeführt werden.Continuous Testing [3] stellt eine neue Praxis für das Testen von Software dar und soll eine schnellere und bessere Markteinführung ermöglichen. Mit diesem Prozess lassen sich Build-, Test- und Bereitstellungs-Workflows automatisieren und so sämtliche Änderungen kontinuierlich, schnell, skalierbar und effizient testen. Sie können automatisierte Tests also während des gesamten Entwicklungszyklus durchführen.Bei der Entwicklung werden die wichtigsten Sprachen und Projekttypen unterstützt. Hierzu zählen Node.js, Python, Java, C#, .NET sowie Android und iOS. Des Weiteren gibt es für Azure DevOps eine Vielzahl von Testframeworks und Services für entsprechende Automatisierungsvorgänge.Azure Pipelines erfordert ein Versionskontrollsystem vom Typ Git oder Azure Repos [4]. Alle Änderungen, die Sie an Ihrem Repository pushen, werden automatisch kompiliert und überprüft.Azure Pipelines bietet also dem Entwicklungsteam eine schnelle, einfache und sichere Möglichkeit, das Erstellen der eigenen Projekte mit konsistentem und qualitativem Code zu automatisieren. Azure Pipelines kann den Entwicklungsprozess bei folgenden Szenarien direkt unterstützen:- Funktionalität mit vielen Sprachen und Plattformen.
- Gleichzeitiges Bereitstellen auf verschiedenen Zieltypen.
- Integration in das Azure-Deployment.
- Integration in Git und Azure Repos.
- Funktionalität mit Open-Source-Projekten.
Kostenloser Testzeitraum
Um mit der Nutzung von Azure Pipelines starten zu können, benötigen Sie ein aktives Azure-Konto. Beachten Sie, dass Microsoft für bestimmte Projektumfänge einen kostenlosen Testzeitraum mit einem Guthaben von 200 US-Dollar zur Verfügung stellt. Eine Nutzung darüber hinaus wird entsprechend in Rechnung gestellt. Zu Test- und Demozwecken kann es aber gut genutzt werden.Die .NET-MAUI-App
Das Projekt .NET-MAUI-App für das nachfolgende Beispiel soll möglichst einfach und überschaubar bleiben. Es wird die Erstellung einer .NET-MAUI-Android-App in Verbindung mit Azure DevOps aufzeigen und über Azure Pipelines die direkte Bereitstellung im Google Play App Store vornehmen. Dieser Vorgang hat sich in vielen Fällen schon als unglaublich praktisch erwiesen, er verbessert den Entwicklungsprozess in Hinsicht auf die Test- und eine entsprechende Wiederholbarkeit bei der Veröffentlichung im Play Store.Zur Erstellung dieses Beispiels wird die Visual Studio Community 2022 Edition mit dem aktuellen .NET Framework verwendet. Zusätzlich sollten Sie Zugriff auf Android 13.0 – API 33 oder höher – haben, um auch den Android-Emulator ausprobieren zu können.Der Download und die Installation für das Android SDK und das Android Device können über den SDK- beziehungsweise Device Manager in Visual Studio ausgeführt werden.Außerdem benötigen Sie eine erstellte Organisation in Azure DevOps, um in der DevOps-Umgebung Zugriff auf Azure Pipelines und Azure Repos zu erhalten. Sollten Sie noch keine Organisation erstellt haben, können Sie dies ganz einfach über den Link unter [5] ausführen.Darüber hinaus benötigen Sie in Ihrer Organisation unter Azure DevOps noch ein entsprechendes Projekt zur Anlage der Azure Pipelines und für den Zugriff auf die Repositories. Legen Sie daher über Create a project to get started ein neues Projekt mit dem Namen DemoAzureApp für Ihre Test- und Demozwecke an. Bild 1 zeigt den zugehörigen Dialog zur Anlage als privates Projekt in DevOps. Schließen Sie das Erzeugen mit Create project ab.
Anlegen des Projekts in Azure DevOps (Bild 1)
Autor
Das Projekt
Nachdem alle Vorbereitungen in Azure DevOps getroffen wurden, können Sie mit der Erstellung der Demo-App fortfahren. Wie gesagt soll das folgende Beispiel unkompliziert sein und sowohl auf Windows- als auch auf Android-Devices ausführbar sein.Starten Sie für das Projekt Visual Studio 2022 als Administra-tor, wählen Sie als Projektvorlage
.NET MAUI App(Bild 2) aus und vergeben Sie als Vorbereitung für die Beispielanwendung den Projektnamen DemoMAUIApp. Bestimmen Sie das aktuelle .NET-Framework und legen Sie den lokalen Speicherort für das Projekt fest. Den Projektdialog schließen Sie mit Create ab. Visual Studio erstellt daraufhin aus der Vorlage automatisch eine bereits lauffähige Multi-Plattform-App.

Auswahl der Projektvorlage .NET MAUI App (Bild 2)
Autor
Die erstellte App aus der Projektvorlage beinhaltet bereits einen Demonstrationscode für einen Button-Click-Event. Die App kann über den Start-Button [F5] auch schon in der Windows-Umgebung gestartet werden.Binden Sie jetzt über die Schaltfläche Open Android SDK Manager das benötigte Android SDK ein und wählen Sie über Open Android Device Manager einen entsprechenden Emulator aus.Nach der Installation der Android-Komponenten können Sie die App über den Startvorgang (Bild 3) in einem Android-Emulator ausführen. Bild 4 zeigt die lauffähige Android-App, die im Folgenden für das Azure-Pipelines-Beispiel verwendet werden kann.

Aufruf der App mit dem Android Emulator (Bild 3)
Autor

Die Android-App ist lauffähig (Bild 4)
Autor
Signaturzertifikat
Wenn Sie eine App für Android in Azure DevOps beziehungsweise in der Pipeline verwenden möchten, benötigen Sie dafür ein Signaturzertifikat über eine Keystore-Datei. Eine solche Keystore-Datei, die Ihr Signaturzertifikat enthält, können Sie in Visual Studio ganz einfach abrufen. Starten Sie dazu in Ihrem DemoMAUIApp-Projekt über View | Terminal die Developer-PowerShell. Über den Befehl keytool in der Befehlszeile können Sie die entsprechende Datei erzeugen. Geben Sie den Befehl wie folgt an:
keytool -genkey -v -keystore
DemoMAUIApp.keystore -alias
DemoMAUIApp -keyalg RSA
-keysize <span class="hljs-number">2048</span> -validity <span class="hljs-number">20000</span>
Der Befehl -genkey erzeugt den Schlüssel mithilfe des RSA-Algorithmus und der vorgegebenen Größe. Die Gültigkeit des Schlüssels wird über -validity in Tagen festgelegt. Vergeben Sie in der PowerShell nach Aufforderung das Passwort, das Sie später in Azure DevOps benötigen. Die nachfolgend gestellten Fragen über Namen und Organisation können Sie fakultativ beantworten. Die Frage nach dem Ländercode dagegen muss beantwortet werden.Nach der Eingabe können Sie die Daten noch einmal validieren und die Einstellungen mit einem ja bestätigen. Bild 5 zeigt die gemachten Angaben und die Generierung des Schlüssels.

Keystore-Aufruf in der PowerShell (Bild 5)
Autor
Repository anlegen
Nachdem der Schritt zur Erstellung der Keystore-Datei abgeschlossen ist, können Sie Ihr aktuelles Projekt in ein Git-Repository verschieben, um es für Azure DevOps und die Pipeline zur Verfügung zu stellen.Öffnen Sie dazu im Solution Explorer von Visual Studio mit der rechten Maustaste das Kontextmenü und wählen Sie darin den Befehl Create Git Repository.Wählen Sie im Dialogfenster den Pfad für Ihr lokales Git-Repository aus und legen Sie unter Push to a new remote den Eintrag Azure DevOps fest.Geben Sie dann unter Create a new Azure DevOps repository Ihren Account, die Organisation und das Projekt an (Bild 6). Schließen Sie das Dialogfenster über den Button Create and Push ab. Visual Studio erstellt daraufhin auch automatisch das Repository in Azure DevOps.
Azure Git Repos anlegen (Bild 6)
Autor
Hochladen der Keystore-Datei
Um mit der Azure Pipeline arbeiten zu können, benötigt Ihr Azure-Projekt nun noch die erzeugte Keystore-Datei. Um diese einzubinden, öffnen Sie Azure DevOps und navigieren zu Ihrem Projekt. Wählen Sie im Menü den Bereich Pipelines | Library aus und klicken Sie auf das Register Secure files(Bild 7). Klicken Sie auf +Secure file und wählen Sie über Browse Ihre erzeugte Keystore-Datei aus. Bestätigen Sie den Upload-Dialog mit OK.
Hochladen der Keystore-Datei (Bild 7)
Autor
Wechseln Sie jetzt auf die Registerkarte Variable groups. Diese Registerkarte dient der sicheren Verwaltung der Keystore-Variablen für die Verwendung in der Pipeline. Erstellen Sie über +Variable group eine neue Gruppe; Sie können hierfür einen beliebigen Namen vergeben. In unserem Beispiel wird Variable Demo App als Name verwendet.Fügen Sie über +Add den Keystore-Alias-Namen hinzu und ebenso den Keystore-Filenamen und das Keystore-Password (Bild 8). Achten Sie dabei darauf, beim Passwort das Symbol Sperren auszuwählen. Dadurch wird Ihr Kennwort geschützt und in allen Protokollen verdeckt.

Anlegen der Variable group (Bild 8)
Autor
Erstellen der Pipeline
Nun ist es an der Zeit, die Pipeline für Continuous Integration und Continuous Delivery zu erstellen.Eine Pipeline kann in Azure aus mehreren Komponenten bestehen. Die wichtigsten Konzepte der Pipeline sind:- Eine Pipeline definiert den kontinuierlichen Integrations- und Bereitstellungsprozess für Ihre Anwendung. Sie stellt einen Workflow (Arbeitsablauf) dar, der definiert, wie Ihre Test-, Build- und Deployment-Schritte ausgeführt werden.
- Stages (Etappen), Jobs und Steps sind die wichtigsten Bausteine einer Pipeline. Eine Stage kann aus einem oder mehreren Jobs bestehen, und Jobs können ihrerseits aus einem oder mehreren Steps bestehen. Ein Step ist der kleinste Baustein einer Pipeline zur Durchführung einer Aktion; das kann ein Task (Aufgabe) oder ein Skript sein.
- Ein Trigger (Auslöser) steuert, wann eine Pipeline ausgeführt wird. Eine Pipeline kann so konfiguriert werden, dass sie bei einem Push an ein Repository, zu geplanten Zeiten oder nach Abschluss eines anderen Builds ausgeführt wird. Alle diese Aktionen werden als Trigger bezeichnet.
- Um eine Pipeline zu starten, ist mindestens ein Agent erforderlich. Der Begriff Agent bezeichnet eine Azure-Infrastruktur, die jeweils einen Auftrag ausführt.

Beispielhafter Ablauf einer Pipeline (Bild 9)
Autor
Es gibt mehrere Möglichkeiten, eine Pipeline auf Azure DevOps einzurichten. In diesem einführenden Beispiel nutzen wir die einfachste Methode über eine YAML-Definition [7].Um eine neue Pipeline zu erstellen, öffnen Sie unter Azure DevOps Ihr Beispielprojekt und wählen aus dem Menü der blauen Schaltfläche den Befehl Pipelines. Klicken Sie dann auf den Button Create Pipeline.Im ersten Schritt müssen Sie den Speicherort Ihres Codes angeben. Wählen Sie für das Beispiel die Option Azure Repos Git. Nun werden alle verfügbaren Repositories aufgelistet. Wählen Sie hier das Beispiel DemoMAUIApp aus.Im nächsten Schritt bietet Azure DevOps einige vordefinierte Vorlagen für verschiedene Pipelines. Hier verwenden wir die Starter-Pipeline, um eine grundlegende Struktur der YAML-Datei zu erhalten. Es wird nun ein Editor angezeigt, der eine aktuelle YAML-Definition enthält.Azure Pipelines unterstützen nicht alle YAML-Funktionen. Zu den nicht unterstützten Features gehören Schlüssel und Sets. Außerdem ist die Pipeline-YAML-Datei darauf angewiesen, dass Stage, Jobs und Task als erste Werte im Mapping erscheinen.Diese YAML-Definition muss jetzt für den Vorgang aktualisiert werden, um die Android-App zu erstellen und die APK- und AAB-Dateien zu erzeugen.Das Android-Paket mit der Dateierweiterung APK stellt die Installationsdatei für die Android-App dar. Google hat ab 2018 das Android App Bundle (AAB) für das Veröffentlichen im Google Play Store eingeführt, um die anfänglichen Downloadgrößen der Apps zu reduzieren, da nur die benötigten Teile auf das Gerät heruntergeladen werden. Um die App auch im Play Store zu veröffentlichen, benötigen Sie also auch die Android-App-Bundle-Dateien.Listing 1 zeigt die komplette Pipeline der zu erstellenden Dateien. Stellen Sie vor einer Übernahme sicher, dass Sie die entsprechenden Namen für Ihr Beispielprojekt anpassen.
Listing 1: Die Pipeline-YAML-Definition
# Pipeline <span class="hljs-keyword">to</span> build .NET apps <span class="hljs-keyword">for</span> Android<br/>name: Build .NET Android app<br/>trigger:<br/> branche<span class="hljs-variable">s:</span><br/> include:<br/> - main<br/># Define variables<br/>variable<span class="hljs-variable">s:</span><br/>- name: <span class="hljs-string">'BUILD_CONFIGURATION'</span><br/> value: <span class="hljs-string">'Release'</span><br/>- name: <span class="hljs-string">'DOTNET_VERSION'</span><br/> value: <span class="hljs-string">'7.0.x'</span><br/>- name: <span class="hljs-string">'FRAMEWORK_ANDROID'</span><br/> value: <span class="hljs-string">'net7.0-android'</span><br/>- name: <span class="hljs-string">'SOLUTION_PATH'</span><br/> value: <span class="hljs-string">'DemoMAUIApp'</span><br/>- name: <span class="hljs-string">'PROJECT_PATH'</span><br/> value: <span class="hljs-string">'DemoMAUIApp/DemoMAUIApp.csproj'</span><br/>- name: <span class="hljs-string">'ARTIFACT_ANDROID_DROP_NAME'</span><br/> value: <span class="hljs-string">'drop-android'</span><br/>- group: <span class="hljs-string">'Variable_Demo_App'</span><br/>stage<span class="hljs-variable">s:</span><br/>- stage: BuildMAUIApps<br/> job<span class="hljs-variable">s:</span><br/> - jo<span class="hljs-variable">b:</span> BuildMAUIAndroid<br/> displayName: Build Android App<br/> poo<span class="hljs-variable">l:</span><br/> vmImage: <span class="hljs-string">'windows-2022'</span><br/> demand<span class="hljs-variable">s:</span><br/> - MSBuild<br/> <br/> step<span class="hljs-variable">s:</span><br/> - task: UseDotNet@<span class="hljs-number">2</span><br/> displayName: .NET Version<br/> <span class="hljs-built_in">input</span><span class="hljs-variable">s:</span><br/> packageType: <span class="hljs-string">'sdk'</span><br/> <span class="hljs-keyword">version</span>: <span class="hljs-string">'$(DOTNET_VERSION)'</span><br/> <br/> - task: CmdLine@<span class="hljs-number">2</span><br/> displayName: Install MAUI<br/> <span class="hljs-built_in">input</span><span class="hljs-variable">s:</span><br/> <span class="hljs-keyword">scrip</span><span class="hljs-variable">t:</span> |<br/> dotnet nuget locals <span class="hljs-keyword">all</span> --clear <br/> dotnet workload install maui<br/> - task: DownloadSecureFile@<span class="hljs-number">1</span><br/> displayName: Download keystore <span class="hljs-keyword">file</span> <br/> name: keystore<br/> <span class="hljs-built_in">input</span><span class="hljs-variable">s:</span><br/> secureFile: <span class="hljs-string">'$(KeyStore-FileName)'</span><br/> - task: CmdLine@<span class="hljs-number">2</span><br/> displayName: Move Keystore <span class="hljs-keyword">to</span> Working <br/> Directory<br/> <span class="hljs-built_in">input</span><span class="hljs-variable">s:</span> <br/> <span class="hljs-keyword">scrip</span><span class="hljs-variable">t:</span> |<br/> mv $(keystore.secureFilePath) <br/> $(System.DefaultWorkingDirectory)<br/> - task: CmdLine@<span class="hljs-number">2</span><br/> displayName: Build App<br/> <span class="hljs-built_in">input</span><span class="hljs-variable">s:</span><br/> <span class="hljs-keyword">scrip</span><span class="hljs-variable">t:</span> |<br/> <span class="hljs-keyword">cd</span> $(SOLUTION_PATH)<br/> dotnet publish $(PROJECT_PATH)<br/> -<span class="hljs-keyword">f</span> $(FRAMEWORK_ANDROID) <br/> -<span class="hljs-keyword">c</span> $(BUILD_CONFIGURATION) <br/> /<span class="hljs-keyword">p</span>:AndroidSigningKeyPass=<br/> $(KeyStore-Password) <br/> /<span class="hljs-keyword">p</span>:AndroidSigningStorePass=<br/> $(KeyStore-Password) <br/> /<span class="hljs-keyword">p</span>:AndroidSigningKeyStore=<br/> $(System.DefaultWorkingDirectory)\\<br/> $(KeyStore-FileName) <br/> /<span class="hljs-keyword">p</span>:AndroidSigningKeyAlias=<br/> $(KeyStore-Alias) <br/> /<span class="hljs-keyword">p</span>:AndroidKeyStore=true<br/> - task: CopyFiles@<span class="hljs-number">2</span><br/> displayName: Copy APK <span class="hljs-built_in">and</span> AAB<br/> <span class="hljs-built_in">input</span><span class="hljs-variable">s:</span><br/> Content<span class="hljs-variable">s:</span> |<br/> **\*Signed.apk<br/> **\*Signed.aab<br/> TargetFolder: <br/> <span class="hljs-string">'$(Build.ArtifactStagingDirectory)'</span><br/> flattenFolder<span class="hljs-variable">s:</span> true<br/> <br/> - task: PublishBuildArtifacts@<span class="hljs-number">1</span><br/> displayName: Publish APK und AAB<br/> <span class="hljs-built_in">input</span><span class="hljs-variable">s:</span><br/> PathtoPublish: <br/> <span class="hljs-string">'$(Build.ArtifactStagingDirectory)'</span><br/> ArtifactName: <br/> <span class="hljs-string">'$(ARTIFACT_ANDROID_DROP_NAME)'</span><br/> publishLocation: <span class="hljs-string">'Container'</span>
Der obere Bereich definiert die Metadaten. Im Beispiel gibt es nur den Hauptzweig main. Das Schlüsselwort variables verbindet die neu erstellte Variablengruppe mit der Pipeline. Des Weiteren werden die verwendete .NET-Version und die Pfade für die App angegeben. Danach wird ein Job mit dem Namen BuildMAUIApp definiert und Windows-2022 als virtuelle Maschine ausgewählt.Der erste Step der Pipeline installiert dann die gewünschte Version des .NET SDK und bindet über den Befehl dotnet workload .NET MAUI mit ein. Dann werden die Daten aus dem Keystore gelesen und die Datei in das System.DefaultWorkingDirectory abgelegt. Der Befehl dotnet publish erstellt und veröffentlicht die App. Zum Schluss werden die Schritte zum Kopieren und Veröffentlichen der entsprechenden APK- und AAB-Dateien vorgenommen.Haben Sie die Anpassungen in der YAML-Definition vorgenommen, können Sie diese speichern und die Pipeline ausführen. Nach erfolgreichem Lauf stehen Ihnen die APK- und AAB-Dateien über den Link Related auf der Übersichtsseite zur Verfügung.
Ressourcen, Parameter und Variablen
Eine Ressource ist alles, was in einer Pipeline verwendet wird und sich dabei außerhalb der Pipeline befindet. Um zum Beispiel eine YAML-Definition in einem anderen Repository zu verwenden, muss das System zunächst dieses Repository kennen. Dazu gehören folgende Angaben:- Repository: Der String zur Identifizierung des Repositorys, das verwendet wird, wenn darauf in der YAML-Datei referenziert wird.
- Typ: Der Git-Typ bezieht sich auf Azure-Git-Repos. Es werden aber auch andere Typen unterstützt, zum Beispiel GitHub.
- Name: Der Repository-Name, wobei das Namensformat vom Typ abhängt.
- Referenz: Der zu verwendende Referenzname.
Listing 2: Einsatz von Variablen und Parametern in YAML
# Repo: MySpace/UserRepo<br/># File: azure-pipelineDemo.yml<br/>name: ci_demo<br/>variable<span class="hljs-variable">s:</span><br/> - name: intThreshold<br/> value: <span class="hljs-number">8.0</span><br/> - name: LintFolder<br/> value: <span class="hljs-string">"folder_dir"</span><br/>trigger:<br/> branche<span class="hljs-variable">s:</span><br/> include:<br/> - master<br/>resource<span class="hljs-variable">s:</span><br/> repositorie<span class="hljs-variable">s:</span><br/> - repository: ci_template<br/> <span class="hljs-built_in">type</span>: git<br/> name: MySpace/Repo1<br/> ref: <span class="hljs-string">'refs/heads/master'</span><br/>stage<span class="hljs-variable">s:</span><br/>- stage: CI_Checks<br/> job<span class="hljs-variable">s:</span><br/> - template: ci_template.yml@ci_template<br/> parameter<span class="hljs-variable">s:</span><br/> pylint_threshold: $(PylintThreshold)<br/> lint_folder: $(LintFolder)
Variablen bieten in der Pipeline eine bequeme Möglichkeit, Informationen festzulegen. Im Gegensatz zu Parametern, die Datentypen wie Zahlen und Strings besitzen, werden alle Variablen als Strings gespeichert und sind veränderbar. Definieren Sie also einen Parametertyp als Zahl und übergeben den Wert aus einer Variablen, kann die Pipeline wegen des nicht übereinstimmenden Datentyps nicht geparst werden.In unserem Beispiel aus Listing 1 haben Sie auch geheime Variablen in der Pipeline verwendet. Es gibt mehrere Möglichkeiten, geheime Variablen in der Pipeline zu setzen:
- Die Variablen können in der Benutzeroberfläche der Pipeline-Einstellung festgelegt werden.
- Die Festlegung von geheimen Variablen in der Variablengruppe und die Einrichtung von Sicherheitskontrollen, wer auf die Variablengruppe zugreifen darf.
- Verwendung von Azure Keyvault zur Speicherung von geschützten Werten und zur Verbindung mit der Pipeline über eine Dienstverbindung.
Google-Play-Konsole
Nachdem Sie über die Pipeline eine entsprechende AAB-Datei für das Anwendungspaket im Google Play Store erstellt haben, können Sie die neue App jetzt auch in der Google Play Console einrichten, um Ihre Android-App zu hosten.Beachten Sie dabei, dass Sie beim ersten Mal Ihr generiertes Bundle manuell in Google Play hinzufügen müssen. Danach kann der Prozess über eine Azure-Pipeline automatisiert übertragen werden.Der erste Schritt besteht darin, ein Google-Cloud-Service-Konto zu erstellen und die benötigte Erweiterung Google Play DevOps [8] für Ihre Azure-Dev-Ops-Organisation zu installieren. Eine ausführliche Dokumentation hierzu finden Sie für die Google Play Console unter [9].Die Konfiguration der DevOps-Pipeline kann auch wieder über eine Standard-Starter-Pipeline erfolgen. Die beiden wichtigsten Änderungen betreffen die Signierung des Builds sowie die Veröffentlichung des signierten AAB-Packages. Laden Sie auch hier zunächst Ihre Keystore-Werte als sichere Datei in Ihre Pipeline. Listing 3 zeigt die entsprechende Implementierung in eine YAML-Pipeline-Datei.Listing 3: Keystore-Werte für die Pipeline verfügbar machen
- <span class="hljs-string">task:</span> DotNetCoreCLI@<span class="hljs-number">2</span><br/> <span class="hljs-string">displayName:</span> <span class="hljs-string">'Build and sign Android target'</span><br/> <span class="hljs-string">inputs:</span><br/> <span class="hljs-string">command:</span> <span class="hljs-string">'publish'</span><br/> <span class="hljs-string">projects:</span> <span class="hljs-string">'**/*.csproj'</span><br/> <span class="hljs-string">publishWebProjects:</span> <span class="hljs-literal">false</span><br/> <span class="hljs-string">arguments:</span> <span class="hljs-string">'-c $(buildConfiguration)</span><br/><span class="hljs-string"> -f net7.0-android </span><br/><span class="hljs-string"> -p:AndroidPackageFormat=aab</span><br/><span class="hljs-string"> -p:AndroidKeyStore=True p:AndroidSigningKeyStore</span><br/><span class="hljs-string"> =$(keystore.secureFilePath)</span><br/><span class="hljs-string"> -p:AndroidSigningStorePass=$(</span><br/><span class="hljs-string"> &lt;var name for keystore password&gt;)</span><br/><span class="hljs-string"> -p:AndroidSigningKeyAlias=$(</span><br/><span class="hljs-string"> &lt;var name for key alias&gt;)</span><br/><span class="hljs-string"> -p:AndroidSigningKeyPass=$(</span><br/><span class="hljs-string"> &lt;var name for key password&gt;)'</span>
Die Veröffentlichung in den Google Play Store zeigt Listing 4. Je nach Build-Setup müssen Sie den Wert für bundleFile anpassen.
Listing 4: Google Play Publishing
- <span class="hljs-string">task:</span> GooglePlayRelease@<span class="hljs-number">4</span><br/> <span class="hljs-string">displayName:</span> <span class="hljs-string">'Publish to Google Play'</span><br/> <span class="hljs-string">inputs:</span><br/> <span class="hljs-string">applicationId:</span> <span class="hljs-string">'com.&lt;your-org&gt;.&lt;your-app&gt;'</span><br/> <span class="hljs-string">serviceConnection:</span> <span class="hljs-string">'Google Play Publishing'</span><br/> <span class="hljs-string">action:</span> <span class="hljs-string">'SingleBundle'</span><br/> <span class="hljs-string">bundleFile:</span> <span class="hljs-string">'$(outputDirectory)/*-Signed.aab'</span><br/> <span class="hljs-string">track:</span> <span class="hljs-string">'internal'</span><br/> <span class="hljs-string">userFraction:</span> <span class="hljs-string">'1.0'</span>
Es gibt noch eine Reihe weiterer Optionen für die Aufgabe von Google-Play-Releases. Im Rahmen dieses Artikels sollte aber nur das grundlegende Szenario beschrieben werden.Wenn Sie die Pipeline ausführen, müssen Sie beim ersten Mal durch einen Klick die Erlaubnis erteilen, Ressourcen verwenden zu dürfen. Die nachfolgenden Läufe benötigen keine manuellen Eingriffe mehr.
Fazit
Beim Erstellen und Veröffentlichen Ihrer .NET-MAUI-Android-App können Sie durch Automatisierungs-Pipelines Deployments, Stabilität und Security sicherstellen. Kombinieren Sie dann noch Pull-Request-Strategien und Genehmigungsprozesse (Approval Gates), lässt sich Ihr Code schnell und sicher in produktive Systeme einspielen. Das Ganze ist wiederholbar und nicht auf fixe, eventuell langgestreckte Release-Zyklen begrenzt. Microsoft schafft es somit, die mobile Architektur über DevOps und Pipelines auch für kleine und mittlere Teams sehr gut verfügbar zu machen. Zu Testzwecken einen Blick darauf zu werfen lohnt sich allemal.Fussnoten
- Continuous Integration bei Wikipedia, http://www.dotnetpro.de/SL2409AzureMobDevEA1
- Continuous Delivery bei Wikipedia, http://www.dotnetpro.de/SL2409AzureMobDevEA2
- Continuous Testing bei Wikipedia, http://www.dotnetpro.de/SL2409AzureMobDevEA3
- Azure Repos, http://www.dotnetpro.de/SL2409AzureMobDevEA4
- Microsoft Learn, Organisation in Azure einrichten, http://www.dotnetpro.de/SL2409AzureMobDevEA5
- Microsoft Learn, Wichtige Konzepte für neue Azure-Pipelines-Benutzer, http://www.dotnetpro.de/SL2409AzureMobDevEA6
- YAML bei Wikipedia, http://www.dotnetpro.de/SL2409AzureMobDevEA7
- Visual Studio Team Services Extension for Google Play, http://www.dotnetpro.de/SL2409AzureMobDevEA8
- Microsoft Learn, Publish to Google Play Store, http://www.dotnetpro.de/SL2409AzureMobDevEA9