© VectorMine/Shutterstock.com
DevOps mit Visual Studio App Center - Teil 2

Build, Distribute und Test


Nachdem wir in Teil 1 das App Center eingerichtet und Telemetrie integriert haben, wollen wir nun den Build-Prozess und die Softwareverteilung automatisieren. Zusätzlich widmen wir uns dem automatisierten Testen des User Interface auf echter Hardware.

Unsere Beispiel-App [1] wollen wir automatisch von App Center bauen lassen. Dafür gibt es die Möglichkeit, unter Build ein Repository hinzuzufügen. Folgende Dienste stehen dort zur Auswahl: Azure DevOps, Bitbucket, GitHub, GitLab.

Aus unserem Repository werden nun alle Branches angezeigt. Pro Branch können wir eine Konfiguration hinterlegen. Alle Einstellungen (Abb. 1) sind auch in der Dokumentation zu Build [2] aufgelistet.

weiher_appcenter_teil2_1.tif_fmt1.jpgAbb. 1: Build-Konfiguration

Mit der Einstellung Project wird definiert, welches Projekt gebaut werden soll. Bei Xamarin ist es möglich, die Projektmappe (.sln) oder das Projekt (.csproj) auszuwählen. Wir wählen hier jeweils für Android und iOS das Projekt aus, da wir nur für die jeweilige Plattform bauen möchten. Je nach Plattform unterscheiden sich die Einstellungen in einigen Punkten.

Als Nächstes können wir mit Configuration die Build-Einstellungen angeben. Hier bietet es sich an, für App Center eine eigene Konfiguration zu erstellen. Damit stellen wir sicher, dass unsere Debug- und Release-Builds unberührt bleiben. Im Visual-Studio-Projekt „AnswerWithNumber“ kopiert man die Einstellung „Release“ und gibt dem einen neuen Namen – in diesem Fall „AppCenter“. Für den Bauvorgang können wir auch die Version für das Xamarin SDK pro Plattform auswählen. Hier muss man darauf achten, dass diese mit den lokalen Builds übereinstimmt. Wenn wir für unsere App iOS als Betriebssystem gewählt haben, können wir auch die Version von Xcode auswählen. Leider ist es des Öfteren der Fall, dass Apple diesen Prozess so umbaut, dass das Xamarin SDK und Xcode sich in bestimmten Konstellationen nicht vertragen. Auch hier gilt: Zuerst lokal testen und dann die Einstellungen übernehmen!

Die Option Build scripts zeigt die hinterlegten Skripte an, die in Bash (iOS und Android) oder PowerShell (UWP) geschrieben werden können. Im Abschnitt „Build Scripts“ wird näher darauf eingegangen. Mit Build type geben wir an, ob die App für den Simulator oder für echte Hardware gebaut werden soll. Im Fall von iOS muss die App für Geräte gebaut werden, da sonst nicht signiert werden kann und somit kein Start auf anderen Geräten möglich ist. Unter Build frequency aktiviere ich für den Master Branch gerne die Auswahlmöglichkeit Build this branch on every push. Damit kann man das Bauen des Masters auslagern und muss sich, wenn richtig konfiguriert wurde, nicht mehr darum kümmern. Durch Aktivieren der Option Automatically increment build number muss man sich ebenfalls nicht mehr um das Hochzählen der Build-Nummer sorgen. Als Unterpunkt kann man hier noch zwischen ID und Zeitstempel wählen. Für die Konfigurationen können auch Variablen vergeben werden, die z. B. in einem Build Script genutzt werden können. Pro Plattform hinterlegen wir an dieser Stelle unsere App-Secrets von App Center. iOS und Android benötigen hier jeweils unterschiedliche Variablennamen, z. B. APPCENTER_ANDROID_SECRET und APPCENTER_IOS_SECRET. Die Werte können auch als Passwort gesichert werden (Schlosssymbol). Sie sind dann nach dem Speichern nicht mehr sichtbar.

Wir brauchen für andere Geräte oder Stores eine Signierung. In der Einstellung Sign builds sind die notwendigen Daten hinterlegt. Mit Test on real device können wir ein Starten der App prüfen und somit zumindest sicherstellen, dass das Werk mit den obigen Einstellungen bis hierhin ausführbar ist. In der Einstellung Distribute wird ein Ziel angegeben, an dem die gebaute Version landen soll. Folgende Möglichkeiten stehen zur Auswahl:

  • Group: Gruppe in App Center

  • Store: App Store bzw. Play Store

Entscheidet man sich für Store, kann noch einmal unterschieden werden, ob die App direkt veröffentlicht wird oder für Betatester zur Verfügung steht (z. B. iOS TestFlight). Unter Advanced findet man mit Build status badge eine weitere Einstellung, die eine schöne Möglichkeit bietet, den Status der Builds darzustellen, z. B. im GitHub Repository (Abb. 2).

weiher_appcenter_teil2_2.tif_fmt1.jpgAbb. 2: Build-Status über Badge

Über die Option Save & Build kann man den Bauvorgang testen oder zunächst nur speichern, um noch zusätzliche Einstellungen vorzunehmen. Zum kompletten Vorgang bekommen wir die uns aus Visual Studio bekannten Logs, mit denen man unter anderem Fehler nachvollziehen kann.

Build-Signierung

Unter iOS brauchen wir für die Signierung das Provisioning Profile, das wir im Apple Developer Portal erstellen können. Zusätzlich benötigen wir noch das dazugehörige Zertifikat *.p12. Hierfür laden wir uns unter Certificates die .cer-Datei herunter und fügen sie der Mac Keychain hinzu. Nun klappen wir das Zertifikat auf und markieren es zusammen mit dem Private Key. Über den Aufruf des Kontextmenüs mit einem Rechtsklick und de...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang