Travis CI : qu'est-ce que c'est, fonctionnalités et utilisation dans le développement d'applications

Qu'est-ce que Travis CI et comment ça fonctionne

Travis CI est un service d'intégration continue cloud qui exécute automatiquement des builds et des tests lors de modifications dans un dépôt Git. Après avoir connecté un dépôt via GitHub ou Bitbucket, Travis CI suit les nouveaux commits, Pull Requests et la création de tags, exécutant la configuration de .travis.yml dans un environnement virtuel isolé.

Le processus de travail de Travis CI comprend trois étapes : déclencheur (push ou Pull Request), configuration de l'environnement (install) et exécution des tâches (script). Le service sélectionne automatiquement une machine virtuelle avec un ensemble d'outils préinstallés — des images macOS avec Xcode pour iOS, des images Linux avec Android SDK et niveaux d'API pour Android.

Travis CI prend en charge Build Matrix — un mécanisme d'exécution parallèle d'une même configuration avec différents paramètres. Par exemple, vous pouvez tester simultanément une application iOS sur Xcode 15 et Xcode 16, et une application Android sur API 33 et API 34. Chaque combinaison s'exécute sur une machine virtuelle séparée, réduisant le temps de validation global.

Travis CI vs autres systèmes CI/CD pour projets mobiles

Travis CI se distingue de Jenkins et GitLab CI par sa simplicité de configuration et l'absence de coûts d'infrastructure. Jenkins nécessite une installation sur un serveur dédié et la configuration d'agents, GitLab CI nécessite une instance GitLab autogérée ou cloud. Travis CI fonctionne par abonnement et ne nécessite pas d'administration de serveurs.

Comparé à GitHub Actions, Travis CI fournit des images macOS plus matures pour les builds iOS et une documentation détaillée sur le développement mobile. GitHub Actions, en revanche, est mieux intégré à l'écosystème GitHub et propose plus d'actions communautaires pour des tâches spécifiques de build mobile.

Pour le développement Android, Travis CI propose des images prêtes à l'emploi avec Android SDK 34, Gradle 8 et le support d'émulateurs. Le temps de démarrage du build est de 45 à 90 secondes, comparable aux concurrents. La limitation principale est la limite de builds parallèles, qui dépend du plan tarifaire.

Architecture et principe de fonctionnement de Travis CI

L'architecture de Travis CI est construite sur des microservices qui gèrent la file d'attente des tâches, l'allocation des machines virtuelles et le traitement des résultats. Lors de la réception d'un webhook de GitHub, la plateforme place la tâche dans une file d'attente, trouve une machine virtuelle disponible avec l'image de langage appropriée et exécute les commandes de .travis.yml.

Chaque build s'exécute dans un environnement isolé avec une image OS propre. Travis CI prend en charge trois types d'environnements : Ubuntu Linux (standard), macOS (pour les builds iOS et macOS) et Windows (pour .NET et UWP). Pour les projets mobiles, le support des images macOS avec Xcode et Fastlane préinstallés est essentiel.

Le cycle de vie du build comprend les phases : before_install (configuration système), install (installation des dépendances), before_script (préparation des tests), script (exécution des tests et du build), after_script (nettoyage). Chaque phase est optionnelle et configurable dans le fichier YAML.

Build Matrix dans Travis CI

Build Matrix permet de tester une application avec différentes versions de langage, SDK ou environnement dans des builds parallèles. La matrice est définie via les clés language, os, env et inclut la génération automatique de toutes les combinaisons possibles. Pour les projets mobiles, c'est pratique pour vérifier la compatibilité avec différentes versions d'iOS ou d'Android API.

Lors de l'utilisation de la matrice, Travis CI lance une machine virtuelle séparée pour chaque combinaison. Cela augmente la consommation totale de minutes de build, mais est crucial pour les projets prenant en charge plusieurs versions d'OS. Limitez la taille de la matrice à 4–6 combinaisons pour un rapport couverture-coût optimal.

Syntaxe de .travis.yml

Le fichier .travis.yml utilise le format YAML et se compose de clés racine : language, os, dist (version de distribution), before_install, install, script et deploy. Chaque clé peut contenir une chaîne, un tableau de commandes ou un dictionnaire pour une configuration plus complexe. Travis CI traite les clés dans un ordre strict, garantissant la prévisibilité de l'exécution du build.

Pour les projets iOS, la clé osx_image avec la version de Xcode est obligatoire, par exemple xcode15.2. Pour Android — la clé android avec les composants SDK. Travis CI prend en charge la clé deploy avec des fournisseurs pour le téléchargement automatique des artefacts vers App Store Connect, Google Play, Firebase ou GitHub Releases après un build réussi.

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

Configuration de .travis.yml pour les projets iOS

Pour les projets iOS, .travis.yml doit spécifier objective-c ou swift comme langage, la version de Xcode via osx_image et l'installation des dépendances via CocoaPods ou Swift Package Manager. Travis CI prend en charge toutes les versions actuelles de Xcode, y compris Xcode 16 avec iOS 18 SDK, permettant de tester les applications sur les dernières API.

Une étape importante est la gestion des certificats pour la signature de code. Utilisez les fichiers chiffrés Travis CI pour stocker les profils de provisionnement et les certificats dans le dépôt. Fastlane Match est également pris en charge via des variables d'environnement TRAVIS chiffrées, simplifiant la configuration de signature pour les builds AdHoc et App Store.

# .travis.yml pour application iOS avec 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

Pour les projets avec tests UI sur XCTest, utilisez la clé destinations dans xcodebuild pour spécifier le simulateur. Travis CI prend en charge l'exécution de simulateurs iOS sur les images macOS sans configuration supplémentaire — le simulateur démarre automatiquement lors de l'exécution de la commande de test xcodebuild test.

Configuration de .travis.yml pour les projets Android

Pour les projets Android, .travis.yml est configuré avec le langage android et les composants SDK spécifiés via la clé android. Travis CI fournit des images Linux avec Java JDK 17 préinstallé, Gradle et Android SDK de base. Les niveaux d'API supplémentaires et build-tools sont installés via sdkmanager dans la phase before_install.

Une optimisation clé pour les builds Android est la mise en cache des répertoires .gradle et .m2. Travis CI prend en charge la mise en cache via la clé cache, réduisant le temps d'installation des dépendances de 120 secondes à 10–15 secondes sur les builds suivants. Spécifiez les chemins de cache pour Gradle wrapper et Android Gradle Plugin.

# .travis.yml pour application Android
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/

Pour exécuter des tests instrumentés sur un émulateur Android, ajoutez une étape before_script avec démarrage de l'émulateur et attente de disponibilité. Travis CI prend en charge l'accélération matérielle KVM sur les images Linux, accélérant considérablement l'exécution des tests UI par rapport à l'émulation logicielle.

Intégration de Travis CI avec GitHub et Bitbucket

Travis CI s'intègre avec GitHub et Bitbucket via une application OAuth qui ajoute un webhook au dépôt pour la notification automatique des nouveaux commits. Après activation du dépôt dans Travis CI, tous les push et Pull Requests déclenchent automatiquement un build, et le statut (passed, failed, pending) s'affiche dans l'interface GitHub.

L'intégration avec GitHub Pull Request est une fonctionnalité clé de Travis CI. Le statut du build s'affiche directement dans la PR, bloquant la fusion en cas d'échec des tests. La configuration de la protection de branche dans GitHub avec Travis CI garantit que seul le code testé atteint la branche principale.

Travis CI prend en charge les variables d'environnement chiffrées pour stocker les jetons App Store Connect, les comptes de service Google Play et les clés de signature. Les variables sont chiffrées via la CLI travis encrypt et ajoutées à .travis.yml, assurant un transfert sécurisé des données sensibles vers le build.

Fichiers chiffrés

Les fichiers chiffrés de Travis CI permettent de stocker les profils de provisionnement et certificats iOS dans un dépôt GitHub sans risque de fuite. Le fichier est chiffré avec la commande travis encrypt-file et déchiffré automatiquement pendant la phase before_install. C'est l'approche standard pour les équipes utilisant Travis CI pour la livraison d'applications iOS.

Avantages et limites de Travis CI

Le principal avantage de Travis CI est l'absence de coûts d'infrastructure. L'équipe n'a pas besoin de configurer un serveur, d'installer un logiciel CI/CD ou de surveiller sa disponibilité. Toute la gestion se résume à l'édition de .travis.yml dans le dépôt. Le plan gratuit pour les dépôts publics fait de Travis CI un choix populaire pour les projets mobiles Open Source.

La limitation de Travis CI est la limite de temps de build et de tâches parallèles sur les plans tarifaires. Pour les équipes avec une fréquence de commits élevée (20+ par jour) et des tests d'intégration longs, les coûts de minutes cloud peuvent dépasser le coût de maintenance d'un serveur Jenkins dédié. Travis CI ne prend pas non plus en charge les images Docker personnalisées sur le plan gratuit.

Pour le développement mobile, Travis CI convient aux équipes qui utilisent GitHub, comptent moins de 10 développeurs et ne nécessitent pas d'infrastructure de build personnalisée. Pour les projets Enterprise avec des exigences de conformité ou la nécessité de compiler sur des machines macOS personnalisées, Jenkins reste une solution plus flexible.