Continuous Integration (CI) — définition, principes et configuration de l’automatisation

Qu’est-ce que Continuous Integration

Continuous Integration (CI) est une méthodologie de développement qui automatise le processus d’intégration du code de plusieurs contributeurs dans une base de code unique. Le terme a été introduit par Martin Fowler au début des années 2000 comme un ensemble de pratiques pour prévenir l’«enfer de l’intégration» — une situation où les développeurs travaillent isolés pendant des semaines et, lors de la fusion des modifications, de nombreux conflits apparaissent nécessitant des jours de résolution manuelle.

Le problème que la CI résout

Sans CI, un développeur termine une fonctionnalité, tente de fusionner ses modifications dans la branche main et découvre que ses collègues ont modifié les mêmes fichiers. La résolution des conflits prend des heures et casse souvent le code fonctionnel. La CI résout ce problème en imposant l’intégration plusieurs fois par jour : plus l’intégration est fréquente, moins il y a de conflits et plus ils sont faciles à résoudre. La pratique montre qu’avec une intégration quotidienne, la résolution de conflit prend quelques minutes, alors qu’avec une intégration hebdomadaire, elle prend des heures.

Impact économique de la CI

Selon l’IBM Systems Sciences Institute, le coût de correction d’un bogue à l’étape de codage est de 25 $, à l’étape de test de 100 $ et à l’étape de production de 2 500 $. La CI déplace la détection des défauts le plus possible vers la gauche (shift left), trouvant les erreurs à l’étape du commit lorsque leur correction est pratiquement gratuite. Les équipes avec CI consacrent en moyenne 15 % de leur temps au débogage, contre 35 % pour les équipes sans CI.

Principes de base de Continuous Integration

Martin Fowler a défini les pratiques clés de la CI qui restent pertinentes indépendamment de la pile technologique. Le respect de ces principes garantit que la CI apporte de la valeur plutôt que de devenir une charge bureaucratique. Le développement mobile impose des exigences supplémentaires, mais le noyau reste inchangé.

Dépôt unique

Tout le code du projet est stocké dans un seul dépôt avec un système de contrôle de version unifié (Git). Une source unique de vérité élimine la situation où une fonctionnalité est développée dans un fork et n’est pas synchronisée avec la base de code principale pendant des semaines. Dans les projets mobiles, cela signifie que les parties Android, iOS et backend peuvent se trouver dans un même dépôt (monorepo) ou dans des dépôts séparés avec un schéma de versionnement partagé.

Build automatisé

Le build du projet doit être exécutable avec une seule commande. Pour Android c’est ./gradlew assembleDebug, pour iOS — xcodebuild ou fastlane build. Le script de build vérifie la reproductibilité : le build sur le serveur CI doit produire le même résultat que sur la machine du développeur. Toute différence d’environnement est éliminée par la conteneurisation ou l’IaC (Infrastructure as Code).

Tests automatisés

Après le build, tous les niveaux de tests sont exécutés : unitaires, d’intégration et d’UI. Si les tests échouent, le commit est considéré comme invalide. Maintenir le statut vert est une responsabilité partagée de l’équipe. Dans les projets mobiles, les tests rapides (exécutés en moins de 5 minutes par commit) sont souvent séparés des tests lents (tests d’UI sur des appareils réels, exécutés moins fréquemment).

// Exemple de test unitaire avec rapport compatible CI
class LoginViewModelTest {

    private val repository = mock<AuthRepository>()
    private val viewModel = LoginViewModel(repository)

    @Test
    fun loginWithValidCredentials_success() {
        val email = "test@example.com"
        val password = "ValidPass123"

        whenever(repository.login(email, password))
            .thenReturn(Result.success(User("token-xyz")))

        val result = viewModel.login(email, password)

        assertEquals(LoginState.Success, result)
        verify(repository).login(email, password)
    }
}

Fail fast et transparence

Les résultats de la CI sont publics pour toute l’équipe : chacun voit quel commit a cassé le build. La transparence crée une culture de responsabilité : les développeurs vérifient leurs modifications avant le push et corrigent le build cassé hors tour. Le serveur CI envoie des notifications sur Slack ou Telegram lorsque le statut du build change.

Composants d’un système CI

Un système CI complet se compose de plusieurs composants qui interagissent entre eux. Chaque composant est responsable de sa partie du pipeline : du déclenchement au rapport. Comprendre l’architecture de la CI aide à diagnostiquer les problèmes et à optimiser les performances.

Serveur CI

Le composant central qui gère la file d’attente des builds, l’allocation des ressources et la publication des résultats. Un serveur CI peut être cloud (GitHub Actions, GitLab CI, CircleCI) ou auto-hébergé (Jenkins, TeamCity). Le serveur surveille les modifications du dépôt via webhook ou polling et déclenche le pipeline à chaque push ou pull request.

Runners et agents

Les runners sont des machines virtuelles ou physiques qui exécutent les tâches de build. Dans la CI cloud, les runners sont fournis par le fournisseur et facturés au temps d’utilisation. Les runners auto-hébergés sont installés sur votre propre infrastructure et nécessitent une maintenance. Les builds iOS nécessitent des runners macOS, les builds Android nécessitent Linux ou Windows.

Artefacts et cache

Après le build, le système CI sauvegarde les artefacts (APK, IPA, rapports de test) dans un stockage — ils sont disponibles pour le téléchargement et le déploiement. La mise en cache des dépendances (cache Gradle, cache CocoaPods) entre les exécutions accélère les builds suivants de 3 à 5 fois.

Continuous Integration pour les applications mobiles

Le développement mobile impose des exigences particulières pour la CI, différentes des projets web ou backend. Les longs temps de build (3–15 minutes pour Android, 5–20 minutes pour iOS), les multiples types d’artefacts (APK, AAB, IPA), la nécessité de signature et d’obfuscation — tout cela nécessite une configuration personnalisée du pipeline CI.

Pipeline CI pour Android

Une CI typique pour Android comprend : linting (ktlint, detekt) et analyse statique, tests unitaires avec JUnit et MockK, build des APK/AAB debug et release, tests instrumentés sur un émulateur dans la CI et publication des artefacts. Le cache Gradle accélère les builds répétés — sans lui, chaque build télécharge les dépendances à nouveau, perdant 3–5 minutes.

Pipeline CI pour iOS

La CI pour iOS nécessite un runner macOS pour compiler le code Swift/Objective-C. Le pipeline comprend : installation des dépendances CocoaPods ou SPM, SwiftLint pour la vérification du style, tests unitaires avec XCTest, build IPA, signature de code via Fastlane match et téléchargement vers TestFlight. Un runner auto-hébergé sur Mac mini ou Mac dans un centre de données est une alternative aux runners macOS cloud.

Projets multiplateformes (Flutter, React Native)

Flutter et React Native se compilent en builds natifs pour les deux plateformes. La CI doit prendre en charge deux runners : Linux pour les builds Android et macOS pour les builds iOS. La stratégie optimale est un pipeline divisé : build Android sur un runner Linux, build iOS sur un runner macOS, après quoi les deux artefacts sont combinés en une seule version.

Comparaison des outils CI

Le choix d’un outil CI dépend de la taille de l’équipe, des performances requises, du budget et de la pile technologique. Voici une comparaison des solutions populaires avec un accent sur le développement mobile. Les solutions auto-hébergées offrent du contrôle mais nécessitent de l’administration ; les solutions cloud offrent de la commodité mais limitent la configuration.

GitHub Actions

Gratuit pour les dépôts publics (2 000 minutes/mois). GitHub Actions offre un écosystème d’actions prêtes à l’emploi pour Android (gradle/actions) et iOS (apple-actions). L’inconvénient est que les runners macOS ne sont disponibles que sur les plans payants. Idéal pour les projets open source et les petites équipes utilisant déjà GitHub.

Jenkins

Un serveur CI auto-hébergé open source. Jenkins se configure via Groovy Pipeline, prend en charge des centaines de plugins et fonctionne sur n’importe quel matériel. Nécessite un ingénieur DevOps pour l’installation et la maintenance. Populaire dans le segment entreprise où le contrôle de l’infrastructure est critique.

GitLab CI

CI/CD intégré dans GitLab avec une architecture de runners ouverte. GitLab CI permet d’utiliser vos propres runners (y compris macOS) sur le plan gratuit. La configuration YAML est plus puissante que GitHub Actions mais plus difficile à apprendre. Convient aux équipes utilisant GitLab comme plateforme DevOps unique.

CircleCI

Une CI cloud axée sur la vitesse. CircleCI prend en charge les images Docker, macOS et Android, et met automatiquement en cache les dépendances. La tarification est basée sur le crédit — plus cher que GitHub Actions pour les petites équipes, mais plus rapide grâce à des runners optimisés. Recommandé pour les projets de production ayant des exigences de vitesse.

Exemple de configuration CI

Examinons la configuration de la CI pour un projet Android avec GitHub Actions. Le pipeline effectue une analyse statique, un build et des tests à chaque push et pull request vers la branche main. La configuration minimale prend 15 minutes et ne nécessite aucun service externe.

name: Android CI
on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - run: ./gradlew ktlintCheck detekt

  unit-tests:
    needs: lint
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-java@v4
        with:
          java-version: 17
          distribution: temurin
      - uses: gradle/actions/setup-gradle@v4
      - run: ./gradlew testDebugUnitTest
      - uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: app/build/reports/tests/

Le pipeline se compose de deux jobs parallèles : lint (effectue l’analyse statique) et unit-tests (dépend de lint — si le linting échoue, les tests ne sont pas exécutés). Le job unit-tests télécharge le rapport de test comme artefact — l’équipe peut le consulter dans l’interface GitHub Actions sans télécharger les fichiers localement.

Vérification locale avant CI

Pour éviter les échecs de CI dus à des erreurs triviales, configurez un hook pre-push dans Git ou une tâche Gradle qui exécute les mêmes vérifications localement. Par exemple : ./gradlew ktlintCheck detekt testDebugUnitTest. Si les vérifications locales prennent plus de 3 minutes, divisez-les en rapides (linter) et lentes (tests), en exécutant les rapides avant chaque commit et les lentes uniquement avant le push.