Einführung in continuous Integration mit Xamarin

Continuous Integration ist eine Softwareentwicklungspraxis, bei der ein automatisierter Build eine App kompiliert und optional testet, wenn Code von Entwicklern im Versionskontrollrepository des Projekts hinzugefügt oder geändert wird. In diesem Artikel werden die allgemeinen Konzepte der Continuous Integration und einige der verfügbaren Optionen für continuous Integration mit Xamarin-Projekten erläutert.

In Softwareprojekten ist es üblich, dass Entwickler parallel arbeiten. Irgendwann ist es notwendig, all diese parallelen Arbeitsströme in eine Codebasis zu integrieren, aus der das Endprodukt besteht. In den frühen Tagen der Softwareentwicklung wurde diese Integration am Ende eines Projekts durchgeführt, was ein schwieriger und riskanter Prozess war.

Continuous Integration (CI) vermeidet solche Komplexitäten, indem die Änderungen jedes Entwicklers kontinuierlich in die gemeinsame Codebasis zusammengeführt werden, in der Regel immer dann, wenn Entwickler Änderungen am freigegebenen Coderepository des Projekts überprüfen. Jedes Einchecken löst einen automatisierten Build aus und führt automatisierte Tests aus, um zu überprüfen, ob der neu eingeführte Code keinen vorhandenen Code unterbricht. Auf diese Weise stellt CI Fehler und Probleme sofort dar und stellt sicher, dass alle Teammitglieder auf dem neuesten Stand bleiben. Dies führt zu einer zusammenhängenden und stabilen Codebasis.

Continuous Integration-Systeme bestehen aus zwei Standard Teilen:

• Versionskontrolle – Versionskontrolle (VC), auch Als Quellcodeverwaltung oder Quellcodeverwaltung bezeichnet, konsolidiert den gesamten Code eines Projekts in einem einzelnen freigegebenen Repository und behält einen vollständigen Verlauf jeder Änderung an jeder Datei bei. Dieses Repository, das häufig als Mainline-Branch bezeichnet wird, enthält den Quellcode, der letztendlich zum Erstellen der Produktions- oder Releaseversion der App verwendet wird. Es gibt viele Open Source und kommerzielle Produkte für diese Aufgabe, die es Teams oder Einzelpersonen in der Regel ermöglichen, eine Kopie des Codes in sekundäre Zweigstellen zu forschen, wo sie umfangreiche Änderungen vornehmen oder Experimente ohne Risiko für die Standard Branch durchführen können. Sobald Änderungen in einem sekundären Branch überprüft wurden, können sie wieder in den Standard-Branch zusammengeführt werden.
• Continuous Integration Server : Der Continuous Integration Server ist für das Sammeln aller Artefakte eines Projekts (Quellcode, Bilder, Videos, Datenbanken, automatisierte Tests usw.), das Kompilieren der App und das Ausführen der automatisierten Tests verantwortlich. Auch hier gibt es viele Open Source und kommerzielle CI-Servertools.

Entwickler verfügen in der Regel über eine Arbeitskopie eines oder mehrerer Branches auf ihren Arbeitsstationen, an denen die Arbeit zunächst erledigt wird. Sobald ein entsprechender Arbeitssatz abgeschlossen ist, werden die Änderungen "eingecheckt" oder an den entsprechenden Branch "gebunden" und an die Arbeitskopien anderer Entwickler weitergegeben. So stellt ein Team sicher, dass alle am selben Code arbeiten.

Auch bei der Continuous Integration führt das Commit von Änderungen dazu, dass der CI-Server das Projekt erstellt und automatisierte Tests ausrichtet, um die Richtigkeit des Quellcodes zu überprüfen. Wenn Buildfehler oder Testfehler auftreten, benachrichtigt ein CI-Server den zuständigen Entwickler (per E-Mail, Chat, Twitter, Growl usw.), damit er das Problem beheben kann. (CI-Server können den Commit sogar ablehnen, wenn Fehler auftreten, was als "gated check-in" bezeichnet wird.)

Das folgende Diagramm veranschaulicht diesen Prozess:

Mobile Apps stellen die Continuous Integration vor einzigartige Herausforderungen. Apps erfordern möglicherweise Sensoren wie GPS oder Kamera, die nur auf physischen Geräten verfügbar sind. Darüber hinaus sind Simulatoren oder Emulatoren nur eine Näherung der Hardware und können Probleme verbergen oder verdecken. Am Ende ist es notwendig, eine mobile App auf echter Hardware zu testen, um sicher zu sein, dass sie wirklich kundenbereit ist.

Der App Center-Test löst dieses spezielle Problem, indem Apps direkt auf Hunderten von physischen Geräten getestet werden. Entwickler schreiben automatisierte Akzeptanztests, die leistungsstarke Benutzeroberflächentests ermöglichen. Sobald diese Tests in App Center hochgeladen wurden, kann der CI-Server sie automatisch als Teil eines CI-Prozesses ausführen, wie im folgenden Diagramm dargestellt:

Komponenten der Continuous Integration

Es gibt ein umfangreiches Ökosystem von kommerziellen und Open-Source-Tools, die zur Unterstützung von CI entwickelt wurden. In diesem Abschnitt werden einige der gängigsten erläutert.

Quellcodeverwaltung

Azure DevOps und Team Foundation Server

Azure DevOps und Team Foundation Server (TFS) sind microsoft's Collaborative Tools für Continuous Integration Build Services, Aufgabennachverfolgung, agile Planungs- und Berichterstellungstools und Versionskontrolle. Mit der Versionskontrolle können Azure DevOps und TFS mit einem eigenen System (Team Foundation-Versionskontrolle oder TFVC) oder mit projekten arbeiten, die auf GitHub gehostet werden.

• Azure DevOps stellt Dienste über die Cloud bereit. Sein Hauptvorteil ist, dass es keine dedizierte Hardware oder Infrastruktur benötigt und von überall über Webbrowser und beliebte Entwicklungstools wie Visual Studio zugänglich ist, was es für Teams attraktiv macht, die geografisch verteilt sind. Es ist kostenlos für Teams mit fünf oder weniger Entwicklern, danach können zusätzliche Lizenzen erworben werden, um ein wachsendes Team aufzunehmen.
• TFS ist für lokale Windows-Server konzipiert und kann über ein lokales Netzwerk oder eine VPN-Verbindung mit diesem Netzwerk zugegriffen werden. Der Hauptvorteil besteht darin, dass Sie die Konfiguration der Buildserver vollständig steuern und alle zusätzlichen Software oder Dienste installieren können, die benötigt werden. TFS bietet eine kostenlose Express-Edition für kleine Teams.

Sowohl TFS als auch Azure DevOps sind eng in Visual Studio integriert und ermöglichen es Entwicklern, viele Versionsverwaltungs- und CI-Aufgaben bequem von einer einzigen IDE aus auszuführen. Das Team Explorer Everywhere-Plug-In für Eclipse (siehe unten) ist ebenfalls verfügbar. Visual Studio für Mac verfügt über eine Vorschau von TFVC.

Azure DevOps Pipelines verfügt über direkte Unterstützung für Xamarin-Projekte, in denen Sie eine Builddefinition für jede Plattform erstellen, auf die Sie abzielen möchten (Android, iOS und Windows). Für jede Builddefinition ist die entsprechende Xamarin-Lizenz erforderlich. Zu diesem Zweck ist es auch möglich, einen lokalen, Xamarin-fähigen TFS-Buildserver mit Azure DevOps zu verbinden. Bei diesem Setup werden Builds, die in Azure DevOps in die Warteschlange gestellt werden, an den lokalen Server delegiert. Ausführliche Informationen finden Sie unter Build- und Release-Agents. Alternativ können Sie ein anderes Buildtool wie Jenkins oder Team City verwenden.

Eine vollständige Zusammenfassung aller Alm-Features (Application Lifecycle Management) von Visual Studio, Azure DevOps und Team Foundation Server finden Sie unter DevOps mit Xamarin Apps.

Team Explorer Everywhere

Team Explorer Everywhere bringt die Leistungsfähigkeit von Team Foundation Server und Azure DevOps für Teams, die sich außerhalb von Visual Studio entwickeln. Entwickler können sich über Eclipse oder den plattformübergreifenden Befehlszeilenclient für OS X und Linux mit Teamprojekten lokal oder in der Cloud verbinden. Team Explorer Everywhere bietet vollständigen Zugriff auf die Versionskontrolle (einschließlich Git), Arbeitselemente und Buildfunktionen für Nicht-Windows-Plattformen.

Git

Git ist eine beliebte Open Source-Lösung zur Versionsverwaltung, die ursprünglich zum Verwalten des Quellcodes für den Linux-Kernel entwickelt wurde. Es ist ein sehr schnelles, flexibles System, das bei Softwareprojekten aller Größen beliebt ist. Es kann problemlos von einzelnen Entwicklern mit schlechtem Internetzugriff auf große Teams skaliert werden, die den ganzen Globus umfassen. Git macht auch die Verzweigung sehr einfach, was wiederum parallele Entwicklungsströme mit minimalem Risiko fördern kann.

Git kann vollständig über Webbrowser oder GUI-Clients ausgeführt werden, die unter Linux, Mac OSX und Windows ausgeführt werden. Es ist kostenlos für öffentliche Repositorys; Private Repositorys erfordern einen kostenpflichtigen Plan.

Aktuelle Versionen von Visual Studio für Windows und Mac bieten native Unterstützung für Git. Microsoft bietet eine herunterladbare Erweiterung für Git für ältere Versionen von Visual Studio. Wie oben erwähnt, können Azure DevOps und TFS Git für die Versionskontrolle anstelle von TFVC verwenden.

Subversion

Subversion (SVN) ist ein beliebtes, Open Source Versionskontrollsystem, das seit 2000 verwendet wird. SVN wird unter allen modernen Versionen von OS X, Windows, FreeBSD, Linux und Unix ausgeführt. Visual Studio für Mac verfügt über native Unterstützung für SVN. Es gibt Erweiterungen von Drittanbietern, die SVN-Unterstützung für Visual Studio bereitstellen.

Continuous Integration-Umgebungen

Das Einrichten einer Continuous Integration-Umgebung bedeutet, ein Versionskontrollsystem mit einem Builddienst zu kombinieren. Für letztere sind die beiden häufigsten:

• Azure Pipelines ist das Buildsystem von Azure DevOps und TFS. Es ist eng in Visual Studio integriert, was es Entwicklern erleichtert, Builds auszulösen, Tests automatisch auszuführen und die Ergebnisse anzuzeigen.
• Jenkins ist ein Open-Source-CI-Server mit einem umfangreichen Ökosystem von Plug-Ins, um alle Arten von Softwareentwicklung zu unterstützen. Es wird unter Windows und Mac OS X ausgeführt. Jenkins ist in keine bestimmte IDE integriert. Stattdessen wird es über eine Webschnittstelle konfiguriert und verwaltet. Jenkins CI ist auch einfach zu installieren und zu konfigurieren, was es für kleine Teams attraktiv macht.

Sie können TFS/Azure DevOps allein oder Jenkins in Kombination mit TFS/Azure DevOps oder Git verwenden, wie in den folgenden Abschnitten beschrieben.

Azure DevOps und Team Foundation Server

Wie bereits erwähnt, bieten Azure DevOps und Team Foundation Server sowohl Versionskontrolle als auch Builddienste. Builddienste erfordern immer eine Xamarin Business- oder Enterprise-Lizenz für jede Zielplattform.

Mit Azure DevOps erstellen Sie eine separate Builddefinition für jede Zielplattform und geben dort die entsprechende Lizenz ein. Nach der Konfiguration führt Azure DevOps Builds und Tests in der Cloud aus. Weitere Informationen finden Sie unter Azure Pipelines .

Mit Team Foundation Server konfigurieren Sie einen Buildcomputer wie folgt für bestimmte Zielplattformen:

• Android und Windows: Installieren Sie Visual Studio und die Xamarin-Tools (für Android und Windows), und konfigurieren Sie sie mit Ihren Xamarin-Lizenzen. Es ist auch erforderlich, das Android SDK an einen freigegebenen Speicherort auf dem Server zu verschieben, an dem der TFS-Build-Agent es finden kann. Ausführliche Informationen finden Sie unter Konfigurieren von TFVC.
• iOS und Xamarin: Installieren Sie Visual Studio und die Xamarin-Tools auf dem Windows-Server mit der entsprechenden Lizenz. Installieren Sie dann Visual Studio für Mac auf einem über das Netzwerk zugänglichen Mac OS X-Computer, der als Buildhost dient und das endgültige App-Paket (IPA für iOS, APP für OS X) erstellt.

Das folgende Diagramm veranschaulicht diese Topografie:

Es ist auch möglich, einen lokalen TFS-Server mit einem Azure DevOps-Projekt zu verknüpfen, sodass Azure DevOps-Builds an den lokalen Server delegiert werden. Ausführliche Informationen finden Sie unter Erstellen und Freigeben von Agents.

Azure DevOps und Jenkins

Wenn Sie Jenkins zum Erstellen Ihrer Apps verwenden, können Sie Ihren Code in Azure DevOps oder Team Foundation Server speichern und Weiterhin Jenkins für Ihre CI-Builds verwenden. Sie können einen Jenkins-Build auslösen, wenn Sie Code an das Git-Repository Ihres Teamprojekts pushen oder Code in TFVC einchecken. Ausführliche Informationen finden Sie unter Jenkins mit Azure DevOps.

Git Und Jenkins

Eine weitere gängige CI-Umgebung kann vollständig OS X-basiert sein. Dieses Szenario umfasst die Verwendung von Git für die Quellcodeverwaltung und Jenkins für den Buildserver. Beide werden auf einem einzelnen Mac OS X-Computer ausgeführt, auf dem Visual Studio für Mac installiert ist. Dies ähnelt der Azure DevOps + Jenkins-Umgebung, die im vorherigen Abschnitt erläutert wurde:

Wichtig

Jenkins wird von Microsoft nicht unterstützt.