Bereitstellung von Apps für Apple Store und Google Play dank Azure DevOps.

Inhaltsverzeichnis

1. Schnelle Auslieferung dank der Azure DevOps-Pipelines
2. Apple Store 
3. Aufbau des iOS Pakets 
4. Release des iOS Pakets in den Apple Store 
5. Google Play 
6. Erstellen des Android Pakets 
7. Signierung des Android Pakets 
8. Upload des Android Pakets 
9. Vor- und Nachteile
10. Zusammenfassung
11. Anhänge

Zu einem früheren Zeitpunkt hatte ich das Problem iOS- und Android-Pakete reibungslos und schnell vom Git-Repository an den Apple Store und an Google Play zu liefern. Ich wusste, dass dieser Lieferprozess während der Entwicklung des Projekts häufig verwendet wird. Aus diesem Grund brauchte ich eine vollautomatische Lösung, mit der wir uns mehr auf die Entwicklung als auf den langfristigen Betrieb konzentrieren können. Mobile Application Stores sind sehr beliebt, daher stellte ich fest, dass sie bereits Lösungen für die kontinuierliche Bereitstellung hatten, mit denen sich die für die Implementierung erforderliche Zeit weiter verkürzen lässt. Gut eine anwendbare, praktikable Lösung zu sehen, die bereits auf dem Markt erhältlich ist. Ich habe beschlossen, alle Anforderungen zu sammeln und die folgende Liste zu erstellen: 

Anforderungen an die angewandte Lösung:

• Einfache Wartung - ein kurzer Prozess mit nur wenigen Schritten;
• Man erfindet das Rad nicht neu, Plug&Play eine perfekte Lösung;
• Selbsterklärende Lösung - Codetyp-Lösung ist erwünscht;
• Schnelle Implementierung - nicht mehr als ein paar Stunden. 

Unter Berücksichtigung dieser Punkte habe ich nur wenige Minuten gebraucht, um eine geeignete Lösung auf Basis von Azure DevOps zu finden. Hiermit beschreibe ich, wie ich mithilfe der Azure DevOps-Pipelines den automatisierten Prozess in weniger als 30 Minuten an die mobilen Stores einrichte.

Schnelle Auslieferung dank der Azure DevOps-Pipelines

Die vorgeschlagene Lösung basiert auf den Azure DevOps-Pipelines, die auf der Azure DevOps-Plattform verfügbar sind. Dieses Tool ist äußerst nützlich, wenn es darum geht, automatisierte Prozesse zu erstellen. Aus diesem Grund habe ich mich für die Verwendung entschieden, zumal das gesamte Projekt bereits auf Azure basiert. 

Unsere Lösung beinhaltet:

• Azure DevOps Pipelines 
• Ansatz der Multi-stage Pipeline
• Pipelines definiert durch yaml Dateien 
• Apple Store 
• Google Play  

Insgesamt wird der Prozess wie folgt aussehen: 

 

Diagramm 1. Aufbau eines Build- und Liefer-Prozesses. 

Apple Store 

In diesem Abschnitt behandeln wir:

• Das Installieren des Bereitstellungsprofils und des Zertifikats aus dem App Store Connect,
• Das Erstellen des iOS-Pakets (.ipa),
• Die Unterzeichnung des Pakets,
• Das Hochladen des Pakets in den Apple Store,
• Die Implementierung aller oben genannten Schritte mithilfe der Azure DevOps-Pipeline.

Bevor wir mit der Azure-Pipeline starten und sie erstellen, müssen zuerst die Voraussetzungen überprüft werden: 

• Das Erstellen der Anwendung im App Store Connect;
• Ein Apple-Entwicklerkonto;
• Das in das Apple Entwickler-Konto hochgeladene iOS-Verteilungszertifikat;
• Ein Apple Entwickler-Konto-Profil, das mit dem oben genannten Zertifikat und der Anwendungspaket-ID im App Store Connect verknüpft ist.

Die gute Information ist, dass alle oben genannten Schritte erforderlich sind, um die Anwendung im Apple Store zu veröffentlichen, auch wenn Sie dies manuell tun möchten. Wenn Sie zu Beginn Ihres Projekts nach Automatisierungslösungen gesucht haben, sind diese wahrscheinlich bereits für Sie verfügbar.

Das folgende Diagramm zeigt diesen gesamten Prozess: 

 

Diagramm 2. Apple Store Prepare-Build-Sign-Release Prozess. 

Werfen wir einen Blick auf die Azure-Pipeline-Konfiguration. Alle Schritte der Pipeline werden in den yaml-Abschnitten dargestellt. Wenn Sie die gesamte yaml-Datei mit allen erforderlichen Schritten benötigen, gehen Sie einfach zum Ende dieses Artikels und verwenden Sie die bereitgestellte Lösung. 

Konfiguration der Azure Pipeline 

name:1.0.$(BuildID)

 

trigger: 

- master 

 

pool: 

  vmImage: 'macOS-10.15' 

 

steps: 

  #Code in the next sections should be copied here 

Der oben angegebene Code sollte am Anfang der Azure Pipeline-yaml-Datei eingefügt werden. Es ist eine Grundkonfiguration, mit der wir:

• Die Namen für alle Builds unserer Pipeline festlegen.
• Einen automatischen Build-Trigger einrichten, immer wenn jemand Änderungen am Hauptzweig vornimmt.
• Den Typ des Build-Agenten als macOS festlegen.
• Die Schritte beschreiben, die während des Laufs dieser Pipeline ausgeführt werden. 

Installieren Sie das Bereitstellungsprofil (Provisioning Profile) und das Zertifikat von App Store Connect 

task: InstallAppleCertificate@2 

  displayName: 'iOS Certificate instalation' 

  inputs: 

    certSecureFile: 'example_certification_file.p12' 

    certPwd: '$(ios_distribution_certification_password)' 

    keychain: 'temp' 

 

- task: InstallAppleProvisioningProfile@1 

  displayName: 'iOS provisioning Profile instalation' 

  inputs: 

    provisioningProfileLocation: 'secureFiles' 

    provProfileSecureFile: 'Example_Distribution.mobileprovision' 

Das Zertifikat und das Bereitstellungsprofil müssen aus dem App Store Connect heruntergeladen und in die Azure Pipelines Library hochgeladen werden. Anschließend kann man mithilfe von zwei einfachen Schritten auf dem Azure Pipeline Marketplace auf dem Build Agent installiert werden. In den nächsten Abschnitten werden die Dateien verwendet, um das ipa-Paket zu erstellen, zu signieren und in den Apple Store hochzuladen. Ich empfehle, die genannten Dateien unter den „sicheren Dateien“ der Azure-Pipelines aufzubewahren, nicht im Repository oder an anderen leicht zugänglichen Stellen.

Die Variable ios_distribution_certification_password sollte dem Ersteller des Zertifikats bekannt sein. Ich empfehle nicht, ein Passwort im yaml-Bereich fest zu codieren. Es ist besser dies im Azure Key Vault, in der Pipeline-Library oder in den Pipeline-Variablen zu speichern, genau wie in meinem Beispiel.

Der oben angegebene Code kann im Abschnitt "Schritte" in der yaml-Datei eingefügt werden.

Aufbau des iOS Pakets 

An diesem Punkt sind wir bereit, unser iOS-Paket (ipa) zu erstellen. Zu diesem Zweck erstellen wir in einem einfachen Schritt iOS mit geringfügigen Änderungen in der Standardkonfiguration. 

task: Xcode@5 

  displayName: 'Build iOS' 

  inputs: 

    actions: 'build' 

    configuration: 'Release' 

    sdk: 'iphoneos' 

    xcWorkspacePath: '**/Example.xcworkspace' 

    scheme: 'ExampleScheme' 

    xcodeVersion: 'specifyPath' 

    xcodeDeveloperDir: '/Applications/Xcode_11.5.app' 

    packageApp: true 

    archivePath: '$(system.defaultworkingdirectory)/archive' 

    signingOption: 'manual' 

    signingIdentity: '$(APPLE_CERTIFICATE_SIGNING_IDENTITY)' 

    provisioningProfileUuid: '$(APPLE_PROV_PROFILE_UUID)'  

Die hervorgehobenen Linien sind hier am wichtigsten. Die Variablen werden automatisch im vorherigen Abschnitt festgelegt, in dem das Bereitstellungsprofil und das Zertifikat installiert wurden. Deshalb muss der Name wie im Beispiel beibehaltet werden. Andere Parameter wie die xcode-Version oder das sdk können entsprechend Ihren Anforderungen geändert werden.

Wie im vorherigen Abschnitt können Sie es direkt nach der Installation des Bereitstellungsprofils in die yaml-Datei im Abschnitt "Schritte" kopieren.

Release des iOS Pakets in den Apple Store 

Endlich ist der Punkt erreicht, an dem das Paket an den Apple Store geliefert werden kann. Um diesen Schritt abzuschließen, verwenden wir erneut einen Azure DevOps-Pipeline-Schritt:

task: AppStoreRelease@1 

  displayName: 'Publish to AppStore' 

  inputs: 

    authType: 'UserAndPass' 

    username: '[email protected]' 

    password: '$(example_username_password)' 

    appIdentifier: '$(bundleid)' 

    appType: 'iOS' 

    ipaPath: '**/*.ipa' 

    releaseTrack: 'TestFlight' 

    shouldSkipWaitingForProcessing: true 

An dieser Stelle müssen die erforderlichen Informationen bereitgestellt werden:

• Ein Benutzername, der zum Hochladen des Pakets in Apple Store Connect verwendet wird.
• Ein Passwort für den Benutzernamen,
• Die Bundle-ID der Anwendung in Apple Store Connect.

Sie können Ihren eigenen Benutzernamen und Ihr eigenes Kennwort für den Apple Store Connect verwenden. Ich empfehle jedoch dringend, ein Dienstkonto zu erstellen und es für diesen Zweck zu verwenden. Es ist sicherer und gewährleistet eine hohe Zuverlässigkeit für das Projekt.

Nach allen genannten Schritten kann unsere Azure-Pipeline ausgeführt und das ipa-Paket an den Apple Store geliefert werden.

Zu beachten ist: 

Speichern Sie Zertifikate, Bereitstellungsprofile und Kennwörter an einem sicheren Ort wie dem Azure Key Vault oder der Azure Pipeline Library.

Erneuern Sie abgelaufene Zertifikate und Bereitstellungsprofile manuell und aktualisieren Sie sie in Azure.

Google Play 

In diesem Abschnitt behandeln wir: 

• Erstellen eines Android-Pakets (.apk)
• Unterzeichnen des Pakets
• Das Paket auf Google Play hochladen
• Implementieren Sie alle oben genannten Schritte mithilfe der Azure DevOps-Pipeline.

Bevor wir die Azure-Pipeline starten und erstellen, überprüfen wir die Voraussetzungen:

• Erstellen eines Dienstkontos und Abruf der JSON-Datei mit ihren Anmeldeinformationen;
• Erstellen eines Anwendungsprojekts mit einer Bundle-ID in Google Play;
• Erstellen des Keystores;
• Manuelles Hochladen der ersten Version des Android-Pakets (.apk) in das Anwendungsprojekt in Google Play;
• Importieren des von Google Play übernommenen Upload-Zertifikats in den Keystore nach dem ersten manuellen Upload des Android-Pakets in Google Play.

Mit Ausnahme des Upload-Zertifikats und des Dienstkontos sind alle anderen Punkte erforderlich, um eine Anwendung manuell in Google Play zu veröffentlichen. Im Vergleich dazu müssen für die Bereitstellung eines Pakets im Apple Store mehr Aktionen ausgeführt werden. Dies zwingt uns dazu, zu Beginn des Projekts mehr Zeit für die Einrichtung eines automatisierten Paketzustellungsprozesses zum mobilen Geschäft aufzuwenden.

Schauen wir uns dieses Diagramm an, um zu überprüfen, wie unser Lieferprozess aussehen wird:

 

 

Diagramm 3. Google Play Build-Sign-Release Prozess.  

Konfiguration der Azure Pipeline 

name: 1.0.$(BuildID)  

 

trigger: 

- master 

 

pool: 

  vmImage: 'ubuntu-18.04' 

 

steps: 

  #Code in the next sections should be copied here 

Der oben angegebene Code sollte am Anfang der Azure Pipeline-yaml-Datei eingefügt werden. Es ist eine Grundkonfiguration, mit der wir:

• Die Namen für alle Builds der Pipeline festlegen.
• Einen automatischen Build-Trigger einstellen, wenn jemand Änderungen am Hauptzweig vornimmt.
• Den Typ des Build-Agenten als Ubuntu festlegen.
• Die Schritte beschreiben, die während des Laufs dieser Pipeline ausgeführt werden. 

Dieser Abschnitt ist dem iOS-Abschnitt sehr ähnlich. Es gibt nur einen Unterschied: den Typ des Build-Agenten. 

Erstellen des Android Pakets 

Der erste Schritt in unserer Android Azure-Pipeline ist die Erstellung unseres Android-Pakets (apk). Meine Anwendung ist in ionisch geschrieben, daher verwende ich den Befehlszeilenschritt, um ionische Befehle auszuführen und die Anwendung in das apk-Paket zu integrieren. Wenn Sie ein anderes Tool wie Xamarin oder Gradle zum Erstellen Ihres Android-Projekts verwenden, können Sie diese auf dem Azure Marketplace suchen. Ich kann Ihnen versichern, dass diese Tools leicht zu finden sind.

task: CmdLine@2 

  displayName: 'Build Android' 

  inputs: 

    script: | 

      ionic cordova platform add android 

      ionic cordova build --configuration prod --release android --verbose 

Mein Build-Schritt ist einfach, da nur zwei Befehle ausgeführt werden, um ein apk-Paket zu erhalten. Dies ist der wichtigste Teil bei der Vorbereitung auf den nächsten Schritt. Wenn Sie ein anderes Tool zum Erstellen des Android-Pakets verwenden, müssen Sie nur sicherstellen, dass das Ergebnis des Build-Schritts das apk-Paket ist und, dass Sie den Speicherort (Pfad) des Pakets auf dem Build-Agenten kennen, da dieser im nächsten Schritt benötigt wird.

Signierung des Android Pakets 

Der zweite Schritt ist wichtig, da wir dann das Paket mit dem richtigen Schlüsselspeicher signieren müssen. Ohne diese Funktion können wir unser Paket nicht in den Store hochladen. Außerdem ist es wichtig, den Keystore mit dem importierten Upload-Zertifikat zu haben. Dieses kann von Google Play heruntergeladen werden.

Bevor wir den Signaturschritt zu unserer Azure-Pipeline hinzufügen, möchte ich Ihnen zeigen, wie Sie den Keystore generieren und das Upload-Zertifikat in ihn importieren. 

Mit dem folgenden Befehl können Sie den Schlüsselspeicher generieren, der für den erforderlichen ersten manuellen Upload des Pakets zu Google Play verwendet werden muss.keytool -v -genkey -v -keystore example.keystore -alias example.alias -keyalg RSA -validity 10000

Um die apk-Datei manuell auf Google Play hochzuladen, müssen Sie sich im Store anmelden, gehen zu „Versionen verwalten“ und laden die Datei hoch auf: Alfa, Beta und Produktion. 

Danach haben Sie die Möglichkeit, das Upload-Zertifikat für die Anwendung herunterzuladen.

Um das Upload-Zertifikat in den neu erstellten Keystore zu importieren, müssen Sie das Upload-Zertifikat von Google Play herunterladen und anschließend den folgenden Befehl ausführen:

keytool -importcert -file. \ upload_cert.der -keystore. \ example.keystore

Eine bereits vorbereitete Keystore-Datei kann in der Azure-Pipeline zum Signieren der apk-Datei verwendet werden.

Dieser Schritt kann schwierig sein. Wenn Sie jedoch bereits über diese Art von Keystore-Datei verfügen, können Sie diese Aufgabe einfach zu Ihrem Schrittabschnitt in der Azure Pipeline-Yaml-Datei hinzufügen: 

task: AndroidSigning@3 

  displayName: 'Sign .apk package' 

  inputs: 

    apkFiles: 'platforms/android/**/*.apk' 

    apksignerKeystoreFile: 'keystore_file' 

    apksignerKeystorePassword: '$(keystore_password)' 

    apksignerKeystoreAlias: 'example.alias' 

Upload des Android Pakets 

Im letzten Schritt können wir unser signiertes apk-Paket in den Google Play Store hochladen, indem wir das Paket mit dem Parameter apk-File auswählen und mit dem Parameter Service-Account-Key den Speicherort der Anmeldeinformationsdatei des Dienstkontos angeben. 

task: GooglePlayRelease@3 

  displayName: 'Upload .apk package' 

  inputs: 

    authType: 'JsonFile' 

    serviceAccountKey: 'service_account_credential_file.json' 

    apkFile: 'platforms/android/**/*.apk' 

    track: 'beta' 

Was mich am meisten überrascht hat, ist die Tatsache, dass die Anmeldeinformationsdatei des Dienstkontos zusammen mit dem Anwendungscode im Repository aufbewahrt werden muss. Zum Zeitpunkt der Erstellung dieses Artikels unterstützt die „GooglePlayRelease“-Task den Azure Key Vault oder die sicheren Dateien in der Azure Pipeline-Bibliothek nicht. Dies ist eine akzeptable Lösung, solange wir den Zugriff auf unser Repository kontrollieren und nicht zulassen, dass anonyme Benutzer auf den Inhalt zugreifen können. Trotzdem ziehe ich es vor, solche kritischen Dateien an sichereren Orten wie dem Azure Key Vault aufzubewahren.

Jetzt können wir unsere Azure-Pipeline ausführen und das apk-Paket an Google Play senden. 

Zu beachten ist:

Bevor wir mit der Erstellung des automatisierten Android-Lieferprozesses beginnen, müssen wir sicherstellen, dass wir den richtigen Schlüsselspeicher mit dem Upload-Zertifikat haben.

Wir sollten ein Dienstkonto erstellen und es im Upload-Schritt verwenden.

Es gibt keine Möglichkeit, die Anmeldeinformationsdatei des Dienstkontos an einem sicheren Ort wie dem Azure Key Vault aufzubewahren. Stattdessen müssen wir sie zusammen mit unserem Anwendungscode im Repository aufbewahren.

Vor- und Nachteile

Einer der Vorteile der beschriebenen Lösung ist ihre Einfachheit. Eine Pipeline mit drei bis vier separaten Schritten in einer für Menschen lesbaren Sprache dank des yaml-Formats. Selbst eine Person, die kein IT-Spezialist ist, kann die gesamte Konfiguration des Pakets für Google Play und den Apple Store verstehen. Ein weiterer Vorteil dieser Lösung ist die Automatisierung - sie erfordert keine zusätzliche Arbeit. Dies beschleunigt die Vorlaufzeit erheblich (Zeit gemessen von einer Änderung im Repository bis zur Lieferung des fertigen Produkts an das Geschäft). Wir haben mehr Zeit, uns auf die Codeentwicklung zu konzentrieren, anstatt auf die für die Veröffentlichung erforderlichen Vorgänge. Da es sich um eine Codelösung handelt, kann sie in jedem VCS versioniert werden, wodurch es sicherer wird neue Änderungen einzuführen. Selbst wenn wir den gesamten Prozess mit einer ungültigen Änderung unterbrechen, können wir diese Änderungen problemlos rückgängig machen und zu einer stabilen Version zurückkehren. Schließlich sind alle erforderlichen Schritte bereits implementiert und auf dem Azure Pipeline Marketplace verfügbar. Sie können es kostenlos nutzen, ohne dass zusätzliche Kenntnisse erforderlich sind.

Andererseits gibt es zwei Nachteile. Einer von ihnen befasst sich mit Apple-Zertifikaten und Apple-Bereitstellungsprofilen. Wenn sie ablaufen, müssen Sie sie manuell erneuern und in die sicheren Dateien in der Azure DevOps-Pipelinebibliothek hochladen. Eine Erinnerung oder eine zusätzliche Lösung wie das Fastlane-Tool kann erforderlich sein, wenn wir den Ablauf vergessen und unser Prozess das Paket nicht an das Geschäft liefern kann. Ein weiterer Nachteil ist die automatische Auslieferung an Google Play, bei der Sie die Anmeldeinformationsdatei generieren und das Upload-Zertifikat in den Keystore importieren müssen. Es ist nicht erforderlich, die App manuell einzureichen, daher verzögert sich der Start des Lieferprozesses. Und nicht unwichtig ist auch die Tatsache, dass es derzeit keine Möglichkeit gibt die Anmeldeinformationsdatei des Dienstkontos an einem sicheren Ort wie dem Azure Key Vault aufzubewahren, sondern es muss im Repository abgelegt werden. Dies kann zu Problemen mit der Sicherheit und Compliance führen.

Zusammenfassung

Das Bereitstellen von Paketen an mobile Geschäfte mithilfe der Azure DevOps Pipelines-Schritte ist einfach und kostengünstig, während die Nachteile relativ gering sind. Alle Schritte sind implementiert, Sie müssen sie nur in Ihren Pipeline-Prozess übernehmen. Darüber hinaus ist die gesamte Konfiguration für jedes andere Projektmitglied sehr einfach und lesbar. Die einfache Implementierung ist ein weiterer Vorteil, insbesondere für diejenigen, die gerade ihre Reise mit den Azure-Pipelines beginnen. Ich bin ein großer Fan dieser Art von Lösung. Hoffentlich werden in naher Zukunft die Azure-Pipeline-Schritte zum Bereitstellen von Paketen an Google Play den Azure Key Vault oder die sicheren Dateien in der Azure-Pipeline-Bibliothek unterstützen. Dies würde diese Lösung sicherer und im Ergebnis sogar noch besser machen. 

Anhänge

Complete Azure Pipeline yaml file for Apple Store delivery 

name: 1.0.$(BuildID)  

 

trigger: 

- master 

 

pool: 

  vmImage: 'macOS-10.15' 

 

steps: 

- task: InstallAppleCertificate@2 

  displayName: 'iOS Certificate instalation' 

  inputs: 

    certSecureFile: 'example_certification_file.p12' 

    certPwd: '$(ios_distribution_cert_password)' 

    keychain: 'temp' 

 

- task: InstallAppleProvisioningProfile@1 

  displayName: 'iOS provisioning Profile instalation' 

  inputs: 

    provisioningProfileLocation: 'secureFiles' 

    provProfileSecureFile: 'Example_Distribution.mobileprovision' 

 

- task: Xcode@5 

  displayName: 'Build iOS' 

  inputs: 

    actions: 'build' 

    configuration: 'Release' 

    sdk: 'iphoneos' 

    xcWorkspacePath: '**/Example.xcworkspace' 

    scheme: 'ExampleScheme' 

    xcodeVersion: 'specifyPath' 

    xcodeDeveloperDir: '/Applications/Xcode_11.5.app' 

    packageApp: true 

    archivePath: '$(system.defaultworkingdirectory)/archive' 

    signingOption: 'manual' 

    signingIdentity: '$(APPLE_CERTIFICATE_SIGNING_IDENTITY)' 

    provisioningProfileUuid: '$(APPLE_PROV_PROFILE_UUID)' 

 

- task: AppStoreRelease@1 

  displayName: 'Publish to AppStore' 

  inputs: 

    authType: 'UserAndPass' 

    username: '[email protected]' 

    password: '$(example_username_password)' 

    appIdentifier: '$(bundleid)' 

    appType: 'iOS' 

    ipaPath: '**/*.ipa' 

    releaseTrack: 'TestFlight' 

    shouldSkipWaitingForProcessing: true 

 

Complete Azure Pipeline yaml file for Google Play delivery 

name: 1.0.$(BuildID)  

 

trigger: 

- master 

 

pool: 

  vmImage: 'ubuntu-18.04' 

 

steps: 

 

- task: CmdLine@2 

  displayName: 'Build Android' 

  inputs: 

    script: | 

      ionic cordova platform add android 

      ionic cordova build --configuration prod --release android --verbose 

 

- task: AndroidSigning@3 

  displayName: 'Sign .apk package' 

  inputs: 

    apkFiles: 'platforms/android/**/*.apk' 

    apksignerKeystoreFile: 'example_keystore' 

    apksignerKeystorePassword: '$(keystore_password)' 

    apksignerKeystoreAlias: 'example.alias' 

 

- task: GooglePlayRelease@3 

  displayName: 'Upload .apk package' 

  inputs: 

    authType: 'JsonFile' 

    serviceAccountKey: 'service_account_credential_file.json' 

    apkFile: 'platforms/android/**/*.apk' 

    track: 'beta'