GitLab CI : pipelines et intégration continue

Qu'est-ce que GitLab CI ?

GitLab CI fait partie de l'application unifiée DevSecOps GitLab, englobant l'intégration, la livraison et le déploiement continus. Le système a débuté comme un projet séparé en 2012 mais a ensuite été intégré directement dans GitLab. Le principe fondamental est la configuration en tant que code via un fichier .gitlab-ci.yml à la racine du dépôt. GitLab CI est disponible à la fois en version cloud SaaS et en installation auto-gérée.

Pour le développement mobile, GitLab CI propose l'automatisation des compilations APK et IPA, l'exécution de tests instrumentés, l'analyse statique de code, la signature d'applications et la publication sur les magasins. La plateforme prend en charge les images Docker pour des environnements personnalisés, permettant la préinstallation d'Android SDK, NDK, Xcode et d'autres outils. Le Container Registry intégré simplifie le stockage et la distribution des images au sein de l'équipe.

Architecture de GitLab CI : Runners, Pipelines et Stages

L'architecture de GitLab CI se compose de trois composants clés. GitLab Runner est un agent qui exécute les jobs. Les runners peuvent être partagés (fournis par GitLab), de groupe (pour un groupe de projets) ou spécifiques (pour un projet). Chaque runner est enregistré avec un executor : Shell, Docker, Kubernetes ou VirtualBox. GitLab Runner prend en charge l'auto-scaling pour gérer les pics de charge.

Un pipeline est un ensemble de stages exécutés séquentiellement. Au sein d'un même stage, les jobs s'exécutent en parallèle. Une structure typique pour un projet mobile est : build → test → deploy. Si un job du stage test échoue, deploy n'est pas déclenché. Un déclenchement manuel (when: manual) peut être configuré pour le déploiement. Les déclencheurs de pipelines multi-projets sont également pris en charge pour des scénarios CI/CD complexes entre dépôts.

Executors de GitLab Runner

L'executor Docker est le plus populaire pour le CI/CD d'applications mobiles. Chaque job s'exécute dans un conteneur Docker propre, garantissant isolation et reproductibilité. Pour les builds Android, l'image android-sdk avec SDK préinstallé est utilisée ; pour iOS, un runner macOS avec executor Shell.

Configuration .gitlab-ci.yml pour les projets mobiles

Le fichier .gitlab-ci.yml définit un pipeline au format YAML. Les sections principales incluent : image (image Docker), stages (liste d'étapes), variables (variables d'environnement), before_script (commandes avant chaque job) et les jobs avec les sections script, artifacts, cache. GitLab CI prend en charge include — l'inclusion de fichiers YAML externes pour réutiliser des configurations communes entre projets.

Les variables dans GitLab CI peuvent être définies à plusieurs niveaux : globalement dans l'interface utilisateur, dans le fichier de configuration, dans les paramètres de groupe et de projet. La priorité des variables suit une hiérarchie : les variables de déclencheur ont la priorité la plus élevée, suivies des variables CI/CD de l'interface, puis du .gitlab-ci.yml. Les variables peuvent être protégées, les rendant accessibles uniquement aux branches et tags protégés.

Variables de base et image

image: openjdk:17-jdk-slim

variables:
  ANDROID_SDK_VERSION: "35"
  GRADLE_OPTS: "-Dorg.gradle.daemon=false"

stages:
  - build
  - test
  - deploy

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/

Job de compilation avec artefacts

Le job generate-apk compile un projet Gradle et sauvegarde l'APK comme artefact. Les artefacts sont transmis entre les stages — un job de deploy peut utiliser l'APK du stage build. La conservation des artefacts est configurée via expire_in.

generate-apk:
  stage: build
  script:
    - ./gradlew assembleRelease
  artifacts:
    paths:
      - app/build/outputs/apk/release/
    expire_in: 1 day

GitLab CI vs GitHub Actions : différences clés

Lors du choix entre GitLab CI et GitHub Actions pour un projet mobile, l'infrastructure de l'équipe est un facteur clé. GitLab CI fournit un Container Registry intégré pour stocker les images Docker avec Android SDK. GitHub Actions dépend de GitHub Packages ou de registres externes. GitLab dispose également d'un SAST (Static Application Security Testing) intégré pour l'analyse des vulnérabilités de code.

GitLab CI offre un modèle de runners plus flexible — il prend en charge l'executor Kubernetes, l'auto-scaling et les images personnalisées. GitHub Actions excelle dans l'intégration avec l'écosystème GitHub et sa marketplace d'actions. GitLab CI nécessite plus de configuration manuelle pour de nombreuses tâches que GitHub Actions résout avec des actions prêtes à l'emploi.

Du point de vue du CI/CD mobile : GitLab CI est mieux adapté aux entreprises utilisant déjà GitLab Self-Managed et nécessitant des runners auto-hébergés avec Docker/Kubernetes. GitHub Actions est plus pratique pour les petites équipes sur GitHub cloud qui apprécient les actions prêtes à l'emploi et la facilité de configuration.

Comparaison des fonctionnalités

Exemple de pipeline pour projet Android

Un pipeline Android complet inclut : lint, tests unitaires, compilation et déploiement vers Firebase App Distribution. Le pipeline utilise une image Docker avec Android SDK, la mise en cache Gradle et l'exécution parallèle de lint et test dans le même stage. Cette approche réduit le temps total du pipeline car les tâches lint et test sont indépendantes l'une de l'autre.

Pour les projets iOS, la structure du pipeline diffère en raison de la nécessité d'un runner macOS et de la signature de code. Un pipeline iOS typique comprend : installation de CocoaPods ou SPM, exécution de tests sur simulateur, archivage du projet Xcode, exportation IPA et téléchargement vers TestFlight. GitLab CI pour iOS utilise des runners macOS — soit les runners SaaS GitLab macOS avec des limites de temps, soit un runner auto-hébergé sur un Mac Mini ou MacStadium.

image: androidsdk/android-35:latest

stages:
  - lint
  - test
  - build
  - deploy

lint-check:
  stage: lint
  script: ./gradlew lint

unit-tests:
  stage: test
  script: ./gradlew test

assemble-release:
  stage: build
  script: ./gradlew assembleRelease
  artifacts:
    paths: [app/build/outputs/apk/release/]

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute
    --app $FIREBASE_APP_ID
    --token $FIREBASE_TOKEN
    --groups testers

Optimisation du temps de compilation dans GitLab CI

L'optimisation des pipelines de compilation mobile dans GitLab CI nécessite une attention aux détails. Une configuration appropriée du cache et des artefacts peut réduire le temps de compilation plusieurs fois. Pour l'analyse des performances, GitLab fournit CI/CD Analytics — un tableau de bord avec des métriques de durée des pipelines, de charge des runners et de goulots d'étranglement. Analysez ces métriques régulièrement pour trouver des opportunités d'optimisation. Configurer resource_group bloque les exécutions parallèles de pipelines — utile pour éviter les conflits de déploiement.

La stratégie de branches pour le CI est également importante. Il est recommandé d'exécuter le pipeline complet uniquement pour les branches main et release, et pour les branches de fonctionnalité — seulement lint et tests unitaires. Cela économise des minutes de runners et accélère le retour aux développeurs. GitLab CI prend en charge workflow:rules — des règles conditionnelles pour inclure ou exclure des jobs en fonction de la branche, des fichiers modifiés ou des variables d'environnement.

La mise en cache des dépendances est la principale méthode d'accélération. GitLab CI met en cache .gradle, Pods et node_modules entre les exécutions. La clé de cache inclut $CI_COMMIT_REF_SLUG ou un hash du fichier lock. Le temps de compilation d'un projet Android passe de 10–15 à 2–4 minutes avec une mise en cache appropriée. Le cache peut être distribué — GitLab prend en charge cache:key avec fallback vers les clés précédentes.

Une image Docker avec des outils préinstallés économise du temps d'installation. Il est recommandé de créer une image personnalisée avec Android SDK, NDK et le niveau d'API requis. L'exécution parallèle des jobs (lint, test, assemble) dans différents stages réduit le temps total du pipeline. Les politiques de pull pour les images (if-not-present) accélèrent le démarrage des jobs. Un proxy de dépendances peut également être utilisé pour mettre en cache les images au niveau de l'instance GitLab.

Un autre aspect important de l'optimisation est l'utilisation des artefacts entre les étapes. Les fichiers lourds comme APK et IPA doivent être transmis via dependency plutôt que d'être reconstruits dans chaque job. Pour les grands projets avec des dizaines de modules, il est recommandé d'activer Gradle Build Cache au niveau du pipeline et de configurer un cache distant sur un stockage partagé. Le timeout de chaque job doit être défini en fonction du temps de compilation prévu — cela évite les processus bloqués.

Exemple avec cache et politique de pull

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .gradle/
    - app/build/

image:
  name: registry.example.com/android-builder:3.5
  pull_policy: if-not-present