Build Pipeline dans le développement mobile — essence, étapes et configuration

Qu'est-ce que Build Pipeline

Build Pipeline est une séquence formalisée d'étapes qui sont exécutées automatiquement à chaque modification de code. Chaque étape vérifie un certain aspect de qualité : compilabilité, exactitude des tests, absence de vulnérabilités, conformité au style de code. Si une étape échoue, le pipeline s'arrête.

Le concept de pipeline vient de la chaîne de production — comme dans une usine où chaque station ajoute de la valeur au produit. Dans le développement, chaque étape ajoute de la confiance que le code est prêt pour la publication. Les pipelines modernes sont définis comme du code (Pipeline as Code) et stockés dans le référentiel Git avec le projet.

Selon la Continuous Delivery Foundation, 2025, un pipeline de compilation mature réduit le temps du commit à la publication de semaines à quelques minutes. Ceci est réalisé grâce à l'automatisation complète et à l'exécution parallèle d'étapes indépendantes.

Pipeline as Code

Au lieu de configurer via une interface web, un pipeline moderne est décrit dans des fichiers YAML ou Groovy. Jenkinsfile, `.gitlab-ci.yml`, `.github/workflows/build.yml` sont des exemples de Pipeline as Code. Avantages : versionnage, révision de code, reproductibilité.

Pipeline déclaratif vs scripté

Jenkins a deux syntaxes. Déclaratif — plus simple, avec une structure claire de stages/steps. Scripté — plus flexible, basé sur Groovy. Pour la plupart des projets, l'approche déclarative est recommandée car plus lisible et prévisible.

Étapes typiques du pipeline

Un pipeline de compilation typique pour une application mobile comprend plusieurs étapes clés. Chaque étape remplit sa fonction et filtre les problèmes potentiels à un stade précoce.

Checkout et installation des dépendances

Le pipeline commence par le clonage du référentiel. Ensuite, les dépendances sont installées : paquets Gradle/Maven, CocoaPods, SPM (Swift Package Manager), paquets npm. L'utilisation du cache à cette étape accélère les compilations ultérieures de 50 à 70%.

Linting et analyse statique

Avant la compilation, des outils de qualité de code sont lancés : Detekt ou ktlint pour Kotlin, SwiftLint pour Swift, ESLint pour JavaScript. Ils vérifient la conformité au style de code et trouvent les bugs potentiels au niveau de l'analyse de code.

Compilation et tests unitaires

Le code est compilé sous forme binaire, les tests unitaires s'exécutent en parallèle. Pour Android, c'est `./gradlew testDebugUnitTest`, pour iOS — `xcodebuild test -scheme App -destination 'platform=iOS Simulator'`. L'échec des tests arrête immédiatement le pipeline.

name: Mobile Build Pipeline
on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew detekt

  unit-tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew testDebugUnitTest
      - run: ./gradlew jacocoTestReport

  build-release:
    needs: [lint, unit-tests]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./gradlew assembleRelease
      - uses: actions/upload-artifact@v4
        with:
          name: release-apk
          path: app/build/outputs/apk/release/app-release.apk

Tests d'intégration et UI

Après une compilation réussie, les tests nécessitant l'exécution de l'application sont effectués : Espresso pour Android, XCTest/XCUITest pour iOS, Detox pour React Native. À cette étape, l'artefact est déployé sur un simulateur ou un appareil réel via des services de ferme (Firebase Test Lab, BrowserStack, Sauce Labs).

Configuration du pipeline

Une configuration appropriée du pipeline détermine l'efficacité de l'ensemble du processus CI/CD. La configuration comprend le choix des déclencheurs, la définition des étapes parallèles et séquentielles, la paramétrisation et l'intégration avec des services externes.

Déclencheurs du pipeline

Principaux déclencheurs : push dans le référentiel, pull request (surtout pour la révision de code avec vérifications automatisées), création de tag Git (pour les compilations de version), planification (nightly build). Le déclencheur pull request est le plus pratique pour le travail d'équipe car il identifie les problèmes avant la fusion du code.

Étapes parallèles et séquentielles

Les étapes indépendantes (linting, tests sur différentes versions d'OS) doivent être exécutées en parallèle pour accélérer. Les dépendantes — séquentiellement. Les systèmes CI modernes gèrent automatiquement les tâches parallèles, les répartissant entre les agents disponibles.

• Fail-fast — configurer l'échec immédiat en cas d'erreur dans toute branche parallèle
• Matrix build — exécution d'une compilation sur plusieurs configurations (API Level, version Xcode)
• Étapes conditionnelles — certaines étapes ne sont exécutées que pour des branches spécifiques (par exemple, déploiement uniquement depuis main)

Optimisation du Build Pipeline

Un pipeline long ralentit le cycle de développement et réduit la motivation de l'équipe. L'optimisation du temps de compilation est l'une des principales tâches d'un ingénieur DevOps lorsqu'il travaille avec des pipelines de compilation.

Mise en cache des dépendances

Gradle Build Cache enregistre les résultats des compilations précédentes. Si le code source d'un module n'a pas changé, il n'est pas recompilé. La compilation incrémentielle dans Swift et Kotlin fonctionne de manière similaire. La taille du cache peut atteindre des gigaoctets, mais l'économie de temps varie de 30% à 70%.

Exécution parallèle des tests

Les tests unitaires peuvent être exécutés sur plusieurs agents simultanément, en répartissant les classes de test. Le sharding est une technique de division des tests en groupes (shards). GitHub Actions prend en charge `strategy.matrix`, Jenkins — Parallel Test Executor, Gradle — `--parallel --max-workers`.

Minimisation des couches du pipeline

Chaque étape supplémentaire ajoute du temps. Analysez régulièrement le pipeline : quelles étapes peuvent être combinées ? Par exemple, le linting peut être exécuté en parallèle de la compilation plutôt qu'avant. Les tests d'intégration — uniquement pour les pull requests, pas pour chaque commit.

pipeline {
    agent any
    options {
        timestamps()
        timeout(time: 30, unit: 'MINUTES')
    }
    stages {
        stage('Parallel Checks') {
            parallel {
                stage('Lint') {
                    steps { sh './gradlew detekt' }
                }
                stage('Unit Tests') {
                    steps { sh './gradlew test' }
                }
            }
        }
        stage('Build') {
            steps { sh './gradlew assembleRelease' }
        }
    }
}

Sécurité du Build Pipeline

Le pipeline de compilation est un élément critique de la chaîne d'approvisionnement logicielle et sa sécurité ne peut être ignorée. Le compromission du pipeline peut entraîner l'injection de code malveillant dans l'artefact de version, affectant tous les utilisateurs de l'application.

Attaques sur la chaîne d'approvisionnement des pipelines

Attaques connues : SolarWinds (2020), Codecov (2021), 3CX (2023) — toutes ont exploité des vulnérabilités dans les pipelines CI/CD. Vecteur commun — un attaquant obtient l'accès aux identifiants du serveur de compilation et modifie le code à l'étape de compilation. Résultat — une version malveillante signée avec un certificat légitime.

Protection des identifiants

Ne stockez jamais les clés de signature, les tokens API et les mots de passe dans le référentiel ou les variables d'environnement du système CI en texte clair. Utilisez les secrets du système CI (GitHub Secrets, GitLab CI Variables), HashiCorp Vault, AWS Secrets Manager. Minimisez l'accès aux secrets — chaque pipeline ne doit recevoir que les clés nécessaires à ses étapes spécifiques.

Vérification des artefacts du pipeline

Chaque artefact sortant du pipeline doit être signé cryptographiquement et contenir une attestation — une preuve d'origine (provenance). Outils : framework SLSA, attestation in-toto, cosign pour la signature de conteneurs. La vérification de la signature doit être effectuée avant le déploiement dans tout environnement.

name: Secure Build Pipeline
on: [push]

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Scan dependencies
        run: ./gradlew dependencyCheckAnalyze
      - name: SAST scan
        run: ./gradlew detekt

  sign-attest:
    needs: security-scan
    runs-on: ubuntu-latest
    steps:
      - run: ./gradlew assembleRelease
      - name: Sign APK
        run: jarsigner -keystore ${{ secrets.KEYSTORE }} \
          app-release.apk ${{ secrets.KEY_ALIAS }}
      - name: Generate provenance
        uses: actions/attest-build-provenance@v1

Surveillance et débogage du pipeline

Le pipeline de compilation est un système complexe qui nécessite une surveillance constante. Sans métriques, il est impossible de déterminer si le pipeline a ralenti et quelle étape est devenue un goulot d'étranglement.

Métriques du pipeline

Suivez : durée totale du pipeline, temps de chaque étape, taux d'échec de compilation, temps d'attente dans la file d'attente. Pour une grande équipe (>20 développeurs), il est recommandé de configurer un tableau de bord dans Grafana ou Datadog avec des statistiques agrégées par semaine/mois.

Alertes en cas d'échec

Chaque échec du pipeline nécessite une réponse. Configurez des notifications dans les messageries (Slack, Telegram, Discord) avec un lien vers le journal d'erreur et le nom de l'auteur du commit. Pour les échecs critiques — PagerDuty ou Opsgenie avec escalade.

Débogage local du pipeline

Des outils comme Act (pour GitHub Actions) ou Jenkins Pipeline Unit Test permettent d'exécuter le pipeline localement sans faire de commit. Cela accélère le développement et le débogage des pipelines, surtout lors de l'ajout de nouvelles étapes ou de la modification de la configuration.