Auf Englisch lesen

Freigeben über


Verwenden von TeamCity mit Xamarin

In diesem Leitfaden werden die Schritte erläutert, die mit der Verwendung von TeamCity zum Kompilieren mobiler Anwendungen und dann zum App Center-Test erforderlich sind.

Wie im Leitfaden zur kontinuierlichen Integration erläutert, ist die kontinuierliche Integration (Continuous Integration, CI) eine nützliche Praxis bei der Entwicklung von qualitativ hochwertigen mobilen Anwendungen. Es gibt viele praktikabele Optionen für die Software für die kontinuierliche Integration von Servern; Dieser Leitfaden konzentriert sich auf TeamCity von JetBrains.

Es gibt mehrere verschiedene Permutationen einer TeamCity-Installation. In der folgenden Liste werden einige dieser Permutationen beschrieben:

  • Windows-Dienst – In diesem Szenario startet TeamCity, wenn Windows als Windows-Dienst gestartet wird. Es muss mit einem Mac Build Host gekoppelt werden, um alle iOS-Anwendungen zu kompilieren.

  • Starten Sie Daemon unter OS X – Konzeptionell ähnelt dies der Ausführung wie ein im vorherigen Schritt beschriebener Windows-Dienst. Standardmäßig werden die Builds unter dem Stammkonto ausgeführt.

  • Benutzerkonto unter OS X – Es ist möglich, TeamCity unter einem Benutzerkonto auszuführen, das jedes Mal gestartet wird, wenn sich der Benutzer anmeldet.

Von den vorherigen Szenarien ist das Ausführen von TeamCity unter einem Benutzerkonto unter OS X die einfachste und einfachste Einrichtung.

Es gibt mehrere Schritte beim Einrichten von TeamCity:

  • Installieren von TeamCity – Die Installation von TeamCity wird in diesem Handbuch nicht behandelt. In diesem Leitfaden wird davon ausgegangen, dass TeamCity unter einem Benutzerkonto installiert und ausgeführt wird. Anweisungen zur Installation von TeamCity finden Sie in der TeamCity 8-Dokumentation von JetBrains.

  • Vorbereiten des Buildservers – Dieser Schritt umfasst die Installation der erforderlichen Software, Tools und Zertifikate, die zum Erstellen mobiler Anwendungen erforderlich sind, und die Vorbereitung auf die Verteilung.

  • Erstellen eines Buildskripts – Dieser Schritt ist nicht unbedingt erforderlich, aber ein Buildskript ist eine nützliche Hilfe für das unbeaufsichtigte Erstellen von Anwendungen. Die Verwendung eines Buildskripts hilft bei der Behandlung von Buildproblemen, die auftreten können, und bietet eine konsistente, wiederholbare Möglichkeit zum Erstellen der Binärdateien für die Verteilung, auch wenn die kontinuierliche Integration nicht praktiziert wird.

  • Erstellen eines TeamCity-Projekts – Sobald die vorherigen drei Schritte abgeschlossen sind, müssen wir ein TeamCity-Projekt erstellen, das alle zum Abrufen des Quellcodes erforderlichen Metadaten enthält, die Projekte kompilieren und die Tests an den App Center-Test übermitteln.

Anforderungen

Die Erfahrung mit dem App Center-Test ist erforderlich.

Die Vertrautheit mit TeamCity 8.1 ist erforderlich. Die Installation von TeamCity liegt außerhalb des Umfangs dieses Dokuments. Es wird davon ausgegangen, dass TeamCity unter OS X Mavericks installiert ist und unter einem regulären Benutzerkonto und nicht unter dem Stammkonto ausgeführt wird.

Der Buildserver sollte ein eigenständiger Computer sein, auf dem OS X ausgeführt wird, der für die kontinuierliche Integration vorgesehen ist. Im Idealfall ist der Buildserver nicht für andere Rollen verantwortlich, z. B. datenbankserver, Webserver oder Entwicklerarbeitsstation.

Wichtig

Dieser Leitfaden deckt keine "kopflose" Installation von Xamarin ab.

Firewall-Konfiguration

Damit Tests an die Xamarin Test Cloud übermittelt werden können, muss der Computer, der die Tests übermittelt, in der Lage sein, mit den Test-Cloud-Servern zu kommunizieren. Firewalls müssen so konfiguriert werden, dass netzwerkdatenverkehr zu und von den Servern, die sich auf testcloud.xamarin.com an den Ports 80 und 443 befinden, zugelassen werden. Dieser Endpunkt wird von DNS verwaltet, und die IP-Adresse kann geändert werden.

In einigen Situationen muss ein Test (oder ein Gerät, auf dem der Test ausgeführt wird) mit Webservern kommunizieren, die durch eine Firewall geschützt sind. In diesem Szenario muss die Firewall so konfiguriert werden, dass Datenverkehr von den folgenden IP-Adressen zugelassen wird:

  • 195.249.159.238
  • 195.249.159.239

Vorbereiten des Buildservers

Ein wichtiger Schritt beim Konfigurieren eines Buildservers besteht darin, alle erforderlichen Tools, Software und Zertifikate zu installieren, um die mobilen Anwendungen zu erstellen. Es ist wichtig, dass der Buildserver die mobile Lösung kompilieren und alle Tests ausführen kann. Um Konfigurationsprobleme zu minimieren, sollten die Software und Tools in demselben Benutzerkonto installiert werden, das TeamCity hosten soll. In der folgenden Liste wird beschrieben, was erforderlich ist:

  1. Visual Studio für Mac – Dazu gehören Xamarin.iOS und Xamarin.Android.
  2. Melden Sie sich beim Xamarin-Komponentenspeicher an – Dieser Schritt ist optional und nur erforderlich, wenn Ihre Anwendung Komponenten aus dem Xamarin-Komponentenspeicher verwendet. Die proaktive Anmeldung beim Komponentenspeicher an diesem Punkt verhindert alle Probleme, wenn ein TeamCity-Build versucht, die Anwendung zu kompilieren.
  3. Xcode – Xcode ist erforderlich, um iOS-Anwendungen zu kompilieren und zu signieren.
  4. Xcode-Befehlszeilentools – Dies wird in Schritt 1 des Installationsabschnitts des Leitfadens zum Aktualisieren von Ruby mit rbenv beschrieben.
  5. Signieren von Identitäts- und Bereitstellungsprofilen – Importieren Sie die Zertifikate und das Bereitstellungsprofil über XCode. Weitere Details finden Sie im Apple-Leitfaden zum Exportieren von Signaturidentitäten und Bereitstellungsprofilen .
  6. Android Keystores – Kopieren Sie die erforderlichen Android-Keystores in ein Verzeichnis, auf das der TeamCity-Benutzer Zugriff hat, d. h. ~/Documents/keystores/MyAndroidApp1.
  7. Calabash – Dies ist ein optionaler Schritt, wenn Ihre Anwendung Tests mit Calabash geschrieben hat. Weitere Informationen finden Sie im Handbuch zum Installieren von Calabash auf OS X Mavericks und im Leitfaden zum Aktualisieren von Ruby mit rbenv .

Das folgende Diagramm veranschaulicht alle diese Komponenten:

This diagram illustrates all of these components

Sobald alle Software installiert sind, melden Sie sich beim Benutzerkonto an, und vergewissern Sie sich, dass alle Software ordnungsgemäß installiert und funktionieren. Dies sollte das Kompilieren der Lösung und das Übermitteln der Anwendung an den App Center-Test umfassen. Dies kann vereinfacht werden, indem Sie das Buildskript ausführen, wie im nächsten Abschnitt beschrieben.

Erstellen eines Buildskripts

Obwohl es für TeamCity möglich ist, alle Aspekte der Kompilierung und Übermittlung mobiler Anwendungen an App Center Test selbst zu behandeln; Es wird empfohlen, ein Buildskript zu erstellen. Ein Buildskript bietet die folgenden Vorteile:

  1. Dokumentation – Ein Buildskript dient als Eine Form der Dokumentation dazu, wie die Software erstellt wird. Dadurch werden einige der "Magie" entfernt, die mit der Bereitstellung der Anwendung verbunden ist, und es Entwicklern ermöglicht, sich auf die Funktionalität zu konzentrieren.
  2. Wiederholbarkeit – Ein Buildskript stellt sicher, dass jedes Mal, wenn die Anwendung kompiliert und bereitgestellt wird, auf die gleiche Weise erfolgt, unabhängig davon, wer oder was die Arbeit ausführt. Diese wiederholbare Konsistenz entfernt alle Probleme oder Fehler, die aufgrund eines falsch ausgeführten Builds oder eines menschlichen Fehlers auftreten können.
  3. Versionsverwaltung – Ein Buildskript kann im Quellcodeverwaltungssystem enthalten sein. Dies bedeutet, dass Änderungen am Buildskript nachverfolgt, überwacht und korrigiert werden können, wenn Fehler oder Ungenauigkeiten gefunden werden.
  4. Vorbereiten der Umgebung – Ein Buildskript kann Logik enthalten, um alle erforderlichen Abhängigkeiten von Drittanbietern zu installieren. Dadurch wird sichergestellt, dass die Anwendungen mit den richtigen Komponenten erstellt werden.

Das Buildskript kann so einfach wie eine PowerShell-Datei (unter Windows) oder ein Bash-Skript (unter OS X) sein. Beim Erstellen des Buildskripts gibt es mehrere Optionen für Skriptsprachen:

  • Rake – dies ist eine Do Standard-Specific Language (DSL) für Bauprojekte, die auf Ruby basieren. Rake hat den Vorteil der Popularität und ein reichhaltiges Ökosystem von Bibliotheken.

  • psake – dies ist eine Windows PowerShell-Bibliothek zum Erstellen von Software

  • FAKE – dies ist ein DSL-basiert in F#, das es möglich macht, vorhandene .NET-Bibliotheken bei Bedarf zu verwenden.

Welche Skriptsprache verwendet wird, hängt von Ihren Einstellungen und Anforderungen ab.

Hinweis

Es ist möglich, ein XML-basiertes Buildsystem wie MSBuild oder NAnt zu verwenden, aber diese fehlen die Ausdrucksfähigkeit und Standard Nachhaltiges eines DSL, das für die Erstellung von Software vorgesehen ist.

Parametrisieren des Buildskripts

Der Prozess des Erstellens und Testens von Software erfordert Informationen, die geheim gehalten werden sollten. Das Erstellen eines APK erfordert möglicherweise ein Kennwort für den Keystore und/oder den Schlüsselalias im Keystore. Ebenso erfordert der App Center-Test einen API-Schlüssel , der für einen Entwickler eindeutig ist. Diese Wertetypen sollten im Buildskript nicht hartcodiert werden. Stattdessen sollten sie als Variablen an das Buildskript übergeben werden.

Weniger vertraulich sind Werte wie die iOS-Geräte-ID oder die Android-Geräte-ID, die identifizieren, welche Geräte App Center für Testläufe verwenden soll. Dies sind keine Werte, die geschützt werden müssen, aber sie können von Build zu Build geändert werden.

Das Speichern dieser Arten von Variablen außerhalb des Buildskripts erleichtert auch das Freigeben des Buildskripts innerhalb einer Organisation, z. B. für Entwickler. Entwickler verwenden möglicherweise dasselbe Skript wie der Buildserver, können aber ihre eigenen Keystores und API-Schlüssel verwenden.

Es gibt zwei mögliche Optionen zum Speichern dieser vertraulichen Werte:

  • Eine Konfigurationsdatei – Um den API-Schlüssel zu schützen, sollte dieser Wert nicht in die Versionssteuerung eingecheckt werden. Die Datei kann für jeden Computer erstellt werden. Wie Werte aus dieser Datei gelesen werden, hängt von der verwendeten Skriptsprache ab.

  • Umgebungsvariablen – diese können einfach pro Computer festgelegt werden und sind unabhängig von der zugrunde liegenden Skriptsprache.

Es gibt Vor- und Nachteile für jede dieser Optionen. TeamCity funktioniert gut mit Umgebungsvariablen, daher wird in diesem Handbuch dieses Verfahren beim Erstellen von Buildskripts empfohlen.

Buildschritte

Das Buildskript muss die folgenden Schritte ausführen:

  • Kompilieren der Anwendung – Dazu gehört das Signieren der Anwendung mit dem richtigen Bereitstellungsprofil.

  • Übermitteln Sie die Anwendung an die Xamarin Test Cloud – Dazu gehört das Signieren und Zippen der APK mit dem entsprechenden Keystore.

Diese beiden Schritte werden unten ausführlicher erläutert.

Kompilieren einer Xamarin.iOS-Anwendung

Die folgende Befehlszeile, um einen Releasebuild der Lösung SOLUTION_FILE.sln für i Telefon anzugeben. Der Speicherort der IPA kann festgelegt werden, indem die IpaPackageDir Eigenschaft in der Befehlszeile angegeben wird:

  • Verwenden Sie auf dem Mac xbuild:

    xbuild /p:Configuration="Release" \ 
           /p:Platform="iPhone" \ 
           /p:IpaPackageDir="$HOME/Builds" \
           /t:Build MyProject.sln
    

Der Befehl "xbuild " befindet sich in der Regel im Verzeichnis "/Library/Frameworks/Mono.framework/Commands".

  • Unter Windows unter Verwendung von msbuild:

    msbuild /p:Configuration="Release" 
            /p:Platform="iPhone" 
            /p:IpaPackageDir="%USERPROFILE%\Builds" 
            /p:ServerAddress="192.168.1.3" /p:ServerUser="macuser"  
            /t:Build MyProject.sln
    

msbuild erweitert $( ) ausdrücke, die von der Befehlszeile übergeben werden, nicht automatisch. Aus diesem Grund wird empfohlen, beim Festlegen der IpaPackageDir Befehlszeile einen vollständigen Pfad zu verwenden.

Weitere Informationen zur IpaPackageDir Eigenschaft finden Sie in den Versionshinweisen für iOS 9.8.

Kompilieren einer Xamarin.Android-Anwendung

Verwenden Sie zum Kompilieren einer Android-Anwendung xbuild (oder msbuild unter Windows):

/Library/Frameworks/Mono.framework/Commands/xbuild /t:SignAndroidPackage /p:Configuration=Release /path/to/android.csproj

Beim Kompilieren der Android-Anwendung xbuild wird das Projekt verwendet, während die iOS-Anwendung xbuild die Lösung verwendet.

Übermitteln von Xamarin.UITests an das App Center

UITests werden mithilfe der App Center CLI übermittelt, wie im folgenden Codeausschnitt gezeigt:

appcenter test run uitest --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK-or-appname.IPA> --merge-nunit-xml report.xml --build-dir pathToUITestBuildDir

Wenn der Test ausgeführt wird, werden die Testergebnisse in Form einer XML-Datei im NUnit-Stil zurückgegeben, die als report.xml bezeichnet wird. TeamCity zeigt die Informationen im Buildprotokoll an.

Weitere Informationen zum Übermitteln von UITests an das App Center finden Sie unter Vorbereiten von Xamarin.Android-Apps oder vorbereiten von Xamarin.iOS-Apps.

Übermitteln von Calabash-Tests an das App Center

Calabash-Tests werden mithilfe der App Center CLI übermittelt, wie im folgenden Codeausschnitt dargestellt:

appcenter test run calabash --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK-or-appname.IPA> --project-dir pathToProjectDir

Um eine Android-Anwendung an app Center Test zu übermitteln, müssen Sie zuerst den APK-Testserver mit calabash-android neu erstellen:

$ calabash-android build </path/to/signed/APK>
$ appcenter test run calabash --app <TEAM-NAME/APP-NAME> --devices <DEVICE_SET> --token <API_KEY> --app-path <appname.APK> --project-dir pathToProjectDir

Weitere Informationen zum Übermitteln von Calabash-Tests finden Sie im Leitfaden von Xamarin zum Übermitteln von Calabash-Tests an die Test-Cloud.

Erstellen eines TeamCity-Projekts

Sobald TeamCity installiert ist und Visual Studio für Mac Ihr Projekt erstellen können, ist es an der Zeit, ein Projekt in TeamCity zu erstellen, um das Projekt zu erstellen und es an Das App Center zu übermitteln.

  1. Begonnen, indem Sie sich über den Webbrowser bei TeamCity anmelden. Navigieren Sie zum Stammprojekt:

    Navigate to the Root Project Erstellen Sie unter dem Stammprojekt ein neues Teilprojekt:

    Navigate to the Root Project Underneath the Root Project, create a new subproject

  2. Nachdem das Teilprojekt erstellt wurde, fügen Sie eine neue Buildkonfiguration hinzu:

    Once the subproject is created, add a new Build Configuration

  3. Fügen Sie ein VCS-Projekt an die Buildkonfiguration an. Dies erfolgt über den Bildschirm "Versionssteuerungseinstellungen":

    This is done via the Version Control Setting screen

    Wenn kein VCS-Projekt erstellt wurde, können Sie ein Projekt auf der unten gezeigten Neuen VCS-Stammseite erstellen:

    If there's no VCS project created, you can create one from the New VCS Root page

    Nachdem der VCS-Stamm angefügt wurde, checkt TeamCity das Projekt aus und versucht, die Erstellungsschritte automatisch zu erkennen. Wenn Sie mit TeamCity vertraut sind, können Sie einen der erkannten Buildschritte auswählen. Es ist sicher, die erkannten Buildschritte für den aktuellen Schritt zu ignorieren.

  4. Konfigurieren Sie als Nächstes einen Buildtrigger. Dadurch wird ein Build in die Warteschlange gestellt, wenn bestimmte Bedingungen erfüllt sind, z. B. wenn ein Benutzer Code für das Repository übernimmt. Der folgende Screenshot zeigt, wie Sie einen Buildtrigger hinzufügen:

    This screenshot shows how to add a build trigger Ein Beispiel für die Konfiguration eines Buildtriggers finden Sie im folgenden Screenshot:

    An example of configuring a build trigger can be seen in this screenshot

  5. Im vorherigen Abschnitt mit der Parameterisierung des Buildskripts wurde vorgeschlagen, einige Werte als Umgebungsvariablen zu speichern. Diese Variablen können der Buildkonfiguration über den Bildschirm "Parameter" hinzugefügt werden. Fügen Sie die Variablen für den App Center-API-Schlüssel, die iOS-Geräte-ID und die Android-Geräte-ID hinzu, wie im folgenden Screenshot gezeigt:

    Add the variables for the App Center Test API Key, the iOS device ID, and the Android Device ID

  6. Der letzte Schritt besteht darin, einen Buildschritt hinzuzufügen, der das Buildskript aufruft, um die Anwendung zu kompilieren und die Anwendung auf Den App Center-Test zu stellen. Der folgende Screenshot ist ein Beispiel für einen Buildschritt, der eine Rakefile zum Erstellen einer Anwendung verwendet:

    This screenshot is an example of a build step that uses a Rakefile to build an application

  7. An diesem Punkt ist die Buildkonfiguration abgeschlossen. Es empfiehlt sich, einen Build auszulösen, um zu bestätigen, dass das Projekt ordnungsgemäß konfiguriert ist. Dies ist eine gute Möglichkeit, eine kleine, unbedeutende Änderung am Repository zu übernehmen. TeamCity sollte den Commit erkennen und einen Build starten.

  8. Überprüfen Sie nach Abschluss des Builds das Buildprotokoll, und überprüfen Sie, ob Probleme oder Warnungen mit dem Build vorhanden sind, die Aufmerksamkeit erfordern.

Zusammenfassung

In diesem Leitfaden wird erläutert, wie Sie Mit TeamCity Xamarin Mobile-Anwendungen erstellen und diese dann an App Center Test übermitteln. Wir haben das Erstellen eines Buildskripts zum Automatisieren des Buildprozesses erörtert. Das Buildskript übernimmt die Kompilierung der Anwendung, das Übermitteln an den App Center-Test und wartet auf die Ergebnisse.

Anschließend wurde erläutert, wie Sie ein Projekt in TeamCity erstellen, das bei jedem Commit eines Entwicklercodes einen Build in die Warteschlange stellt und das Buildskript aufruft.