Travis CI: was es ist, Funktionen und Einsatz in der Anwendungsentwicklung

Was ist Travis CI und wie funktioniert es

Travis CI ist ein Cloud-basierter Continuous-Integration-Dienst, der automatisch Builds und Tests ausführt, wenn Änderungen an einem Git-Repository vorgenommen werden. Nach dem Verbinden eines Repositorys über GitHub oder Bitbucket verfolgt Travis CI neue Commits, Pull Requests und die Erstellung von Tags und führt die Konfiguration aus .travis.yml in einer isolierten virtuellen Umgebung aus.

Der Arbeitsablauf von Travis CI besteht aus drei Phasen: Auslöser (Push oder Pull Request), Umgebungseinrichtung (install) und Aufgabenausführung (script). Der Dienst wählt automatisch eine virtuelle Maschine mit einem vorinstallierten Toolset aus — macOS-Images mit Xcode für iOS, Linux-Images mit Android SDK und API-Levels für Android.

Travis CI unterstützt Build Matrix — einen Mechanismus zur parallelen Ausführung derselben Konfiguration mit verschiedenen Parametern. Beispielsweise können Sie eine iOS-Anwendung gleichzeitig auf Xcode 15 und Xcode 16 testen und eine Android-Anwendung auf API 33 und API 34. Jede Kombination wird auf einer separaten virtuellen Maschine ausgeführt, was die Gesamtvalidierungszeit verkürzt.

Travis CI vs andere CI/CD-Systeme für Mobilprojekte

Travis CI unterscheidet sich von Jenkins und GitLab CI durch den Fokus auf einfache Einrichtung und fehlende Infrastrukturkosten. Jenkins erfordert die Installation auf einem eigenen Server und die Konfiguration von Agents, GitLab CI eine selbstverwaltete oder Cloud-GitLab-Instanz. Travis CI arbeitet abonnementbasiert und erfordert keine Serververwaltung.

Im Vergleich zu GitHub Actions bietet Travis CI ausgereiftere macOS-Images für iOS-Builds und detaillierte Dokumentation zur Mobilanwendungsentwicklung. GitHub Actions hingegen ist besser in das GitHub-Ökosystem integriert und verfügt über mehr Community-Aktionen für spezifische mobile Build-Aufgaben.

Für die Android-Entwicklung bietet Travis CI vorgefertigte Images mit Android SDK 34, Gradle 8 und Emulator-Unterstützung. Die Build-Startzeit beträgt 45–90 Sekunden, vergleichbar mit der Konkurrenz. Die Haupteinschränkung ist das Limit für parallele Builds, das vom Tarif abhängt.

Architektur und Funktionsweise von Travis CI

Die Architektur von Travis CI basiert auf Mikrodiensten, die die Job-Warteschlange, die Zuweisung virtueller Maschinen und die Ergebnisverarbeitung verwalten. Beim Empfang eines Webhooks von GitHub stellt die Plattform den Job in eine Warteschlange, findet eine verfügbare virtuelle Maschine mit dem entsprechenden Sprach-Image und führt die Befehle aus .travis.yml aus.

Jeder Build wird in einer isolierten Umgebung mit einem sauberen Betriebssystem-Image ausgeführt. Travis CI unterstützt drei Umgebungstypen: Ubuntu Linux (Standard), macOS (für iOS- und macOS-Builds) und Windows (für .NET und UWP). Für mobile Projekte ist die Unterstützung von macOS-Images mit vorinstalliertem Xcode und Fastlane entscheidend.

Der Build-Lebenszyklus umfasst Phasen: before_install (Systemeinrichtung), install (Abhängigkeiten installieren), before_script (Testvorbereitung), script (Tests und Build ausführen), after_script (Bereinigung). Jede Phase ist optional und in der YAML-Datei konfigurierbar.

Build Matrix in Travis CI

Build Matrix ermöglicht das Testen einer Anwendung mit verschiedenen Sprach-, SDK- oder Umgebungsversionen in parallelen Builds. Die Matrix wird über die Schlüssel language, os, env definiert und beinhaltet die automatische Generierung aller möglichen Kombinationen. Für mobile Projekte ist dies nützlich, um die Kompatibilität mit verschiedenen iOS- oder Android-API-Versionen zu überprüfen.

Bei Verwendung der Matrix startet Travis CI eine separate virtuelle Maschine für jede Kombination. Dies erhöht den Gesamtverbrauch an Build-Minuten, ist aber für Projekte, die mehrere Betriebssystemversionen unterstützen, von entscheidender Bedeutung. Begrenzen Sie die Matrixgröße auf 4–6 Kombinationen für ein optimales Verhältnis von Abdeckung zu Kosten.

.travis.yml-Syntax

Die Datei .travis.yml verwendet das YAML-Format und besteht aus Root-Schlüsseln: language, os, dist (Distributionsversion), before_install, install, script und deploy. Jeder Schlüssel kann eine Zeichenfolge, ein Befehlsarray oder ein Wörterbuch für komplexere Konfigurationen enthalten. Travis CI verarbeitet die Schlüssel in strenger Reihenfolge und gewährleistet so die Vorhersagbarkeit der Build-Ausführung.

Für iOS-Projekte ist der Schlüssel osx_image mit der Xcode-Version obligatorisch, z. B. xcode15.2. Für Android — der Schlüssel android mit SDK-Komponenten. Travis CI unterstützt den Schlüssel deploy mit Anbietern für den automatischen Upload von Artefakten zu App Store Connect, Google Play, Firebase oder GitHub Releases nach einem erfolgreichen Build.

# .travis.yml mit Build Matrix für iOS
language: objective-c
os: osx
osx_image: xcode15.2
env:
  - SCHEME=App-iOS
  - SCHEME=App-tvOS
script:
  - xcodebuild -scheme $SCHEME clean build test

Konfiguration von .travis.yml für iOS-Projekte

Für iOS-Projekte muss .travis.yml objective-c oder swift als Sprache, die Xcode-Version über osx_image und die Installation von Abhängigkeiten über CocoaPods oder Swift Package Manager angeben. Travis CI unterstützt alle aktuellen Xcode-Versionen, einschließlich Xcode 16 mit iOS 18 SDK, sodass Anwendungen mit den neuesten APIs getestet werden können.

Ein wichtiger Schritt ist die Verwaltung von Zertifikaten für die Codesignierung. Verwenden Sie verschlüsselte Travis CI-Dateien, um Provisioning-Profile und Zertifikate im Repository zu speichern. Fastlane Match wird ebenfalls über verschlüsselte TRAVIS-Umgebungsvariablen unterstützt, was die Signierungseinrichtung für AdHoc- und App Store-Builds vereinfacht.

# .travis.yml für iOS-Anwendung mit Fastlane
language: swift
os: osx
osx_image: xcode15.2
branches:
  only:
    - main
    - /\d+\.\d+\.\d+/
before_install:
  - gem install cocoapods
  - gem install fastlane
install:
  - pod install --repo-update
script:
  - fastlane scan
  - fastlane gym

Für Projekte mit UI-Tests auf XCTest verwenden Sie den Schlüssel destinations in xcodebuild, um den Simulator anzugeben. Travis CI unterstützt die Ausführung von iOS-Simulatoren auf macOS-Images ohne zusätzliche Konfiguration — der Simulator startet automatisch bei der Ausführung des xcodebuild test-Befehls.

Konfiguration von .travis.yml für Android-Projekte

Für Android-Projekte wird .travis.yml mit der Sprache android und über den Schlüssel android angegebenen SDK-Komponenten konfiguriert. Travis CI stellt Linux-Images mit vorinstalliertem Java JDK 17, Gradle und basis Android SDK bereit. Zusätzliche API-Levels und Build-Tools werden in der before_install-Phase über sdkmanager installiert.

Eine wichtige Optimierung für Android-Builds ist das Caching der Verzeichnisse .gradle und .m2. Travis CI unterstützt Caching über den cache-Schlüssel, wodurch die Installationszeit für Abhängigkeiten bei nachfolgenden Builds von 120 Sekunden auf 10–15 Sekunden reduziert wird. Geben Sie Cache-Pfade für Gradle Wrapper und Android Gradle Plugin an.

# .travis.yml für Android-Anwendung
language: android
dist: jammy
jdk: oraclejdk17
android:
  components:
    - tools
    - platform-tools
    - build-tools-34.0.0
    - android-34
    - extra-google-m2repository
before_script:
  - yes | sdkmanager "platforms;android-34"
script:
  - ./gradlew assembleDebug testDebugUnitTest
cache:
  directories:
    - $HOME/.gradle/caches/
    - $HOME/.gradle/wrapper/

Um instrumentierte Tests auf einem Android-Emulator auszuführen, fügen Sie eine before_script-Phase mit Emulator-Start und Warten auf Bereitschaft hinzu. Travis CI unterstützt KVM-Hardwarebeschleunigung auf Linux-Images, was die Ausführung von UI-Tests im Vergleich zur Software-Emulation erheblich beschleunigt.

Integration von Travis CI mit GitHub und Bitbucket

Travis CI integriert sich mit GitHub und Bitbucket über eine OAuth-Anwendung, die ein Webhook zum Repository für automatische Benachrichtigung über neue Commits hinzufügt. Nach der Aktivierung des Repositorys in Travis CI lösen alle Pushs und Pull Requests automatisch einen Build aus, und der Status (passed, failed, pending) wird in der GitHub-Oberfläche angezeigt.

Die Integration mit GitHub Pull Request ist eine Schlüsselfunktion von Travis CI. Der Build-Status wird direkt im PR angezeigt und blockiert das Mergen bei fehlgeschlagenen Tests. Die Konfiguration des Branch-Schutzes in GitHub zusammen mit Travis CI stellt sicher, dass nur getesteter Code in den Haupt-Branch gelangt.

Travis CI unterstützt verschlüsselte Umgebungsvariablen zum Speichern von App Store Connect-Tokens, Google Play-Dienstkonten und Signierschlüsseln. Variablen werden über die travis encrypt-CLI verschlüsselt und zu .travis.yml hinzugefügt, was eine sichere Übertragung sensibler Daten an den Build gewährleistet.

Arbeiten mit verschlüsselten Dateien

Verschlüsselte Dateien in Travis CI ermöglichen die Speicherung von iOS-Provisioning-Profilen und Zertifikaten in einem GitHub-Repository ohne Leckagerisiko. Die Datei wird mit dem Befehl travis encrypt-file verschlüsselt und während der before_install-Phase automatisch entschlüsselt. Dies ist der Standardansatz für Teams, die Travis CI für die iOS-App-Auslieferung verwenden.

Vorteile und Grenzen von Travis CI

Der Hauptvorteil von Travis CI sind die Null-Infrastrukturkosten. Das Team muss keinen Server einrichten, keine CI/CD-Software installieren oder deren Verfügbarkeit überwachen. Die gesamte Verwaltung beschränkt sich auf die Bearbeitung von .travis.yml im Repository. Der kostenlose Plan für öffentliche Repositorys macht Travis CI zu einer beliebten Wahl für Open-Source-Mobilprojekte.

Die Einschränkung von Travis CI ist das Build-Zeitlimit und die Grenzen für parallele Jobs in den Tarifplänen. Für Teams mit hoher Commit-Frequenz (20+ pro Tag) und langen Integrationstests können die Cloud-Minuten-Kosten die Kosten für die Wartung eines eigenen Jenkins-Servers übersteigen. Travis CI unterstützt auch keine benutzerdefinierten Docker-Images im kostenlosen Plan.

Für die mobile Entwicklung ist Travis CI für Teams geeignet, die GitHub verwenden, weniger als 10 Entwickler haben und keine benutzerdefinierte Build-Infrastruktur benötigen. Für Enterprise-Projekte mit Compliance-Anforderungen oder der Notwendigkeit, auf eigenen macOS-Maschinen zu bauen, bleibt Jenkins die flexiblere Lösung.