CircleCI : bases, orbs et intégration continue

Architecture de CircleCI : Orbs, Executors et Contexts

L'architecture de CircleCI se compose de trois niveaux : Pipeline, Workflow et Job. Pipeline est le processus racine déclenché lors d'un commit. Un Pipeline se compose de Workflows — un graphe de Jobs qui peuvent s'exécuter séquentiellement ou en parallèle. Chaque Job s'exécute sur un Executor — un environnement avec une image spécifique. Un Workflow peut inclure des approval gates — une confirmation manuelle avant le déploiement.

Les orbs sont des paquets de configuration YAML réutilisables distribués via CircleCI Orb Registry. Un Orb peut contenir des jobs, commands, executors et des exemples. Orbs populaires : android, ios, flutter, firebase, slack. Par exemple, l'ajout de l'orb android remplace plus de 50 lignes de configuration par une seule ligne. CircleCI CLI permet de créer, tester et publier vos propres orbs pour standardiser les pipelines au sein de l'organisation.

Types d'Executors

Les Contexts sont des ensembles nommés de variables d'environnement disponibles au niveau de l'organisation. Par exemple, le contexte app-store-credentials contient l'Apple ID et le mot de passe pour publier sur l'App Store. Cela simplifie la gestion des secrets entre projets sans duplication.

Configuration de CircleCI pour les projets Android et iOS

Pour un projet Android, CircleCI utilise l'image Docker cibuilds/android avec Android SDK. Un workflow typique comprend : checkout, installation du JDK, mise en cache de Gradle, build et exécution des tests. Pour iOS, un exécuteur macOS avec Xcode et configuration de code signing est requis. Lors de la première connexion, CircleCI détecte automatiquement le type de projet et génère une configuration de base avec les paramètres recommandés.

Pour les projets Flutter, CircleCI fournit l'orb circleci/flutter, qui comprend des exécuteurs avec Flutter SDK préinstallé pour Linux et macOS. L'orb prend en charge la compilation pour les deux plateformes, la mise en cache de pub-cache et l'exécution des tests. La configuration se résume à spécifier la version de Flutter et les commandes de build. Pour les versions personnalisées de Flutter ou Dart, vous pouvez utiliser une image Docker avec le SDK requis. L'orb Flutter prend également en charge des options avancées — par exemple, l'analyse de code via dart analyze avant le build.

Orb Android — démarrage rapide

L'orb Android de CircleCI fournit des jobs prêts à l'emploi : build-and-test, deploy-to-play-store. L'orb configure automatiquement l'environnement, la mise en cache et la signature. Après avoir ajouté l'orb, vous devez simplement spécifier la version du SDK et les commandes de build.

Build iOS avec exécuteur macOS

Pour les builds iOS, l'exécuteur est défini sur macos avec une version de Xcode. CircleCI fournit des images avec Xcode 14, 15 et 16. Après le checkout, le code est compilé via xcodebuild et les tests sont exécutés sur le simulateur. Le code signing est configuré via fastlane match ou l'installation manuelle de certificats.

Mise en cache et exécution parallèle

La mise en cache est un élément clé des performances dans CircleCI. Le mécanisme de cache sauvegarde les répertoires entre les exécutions de workflow à l'aide d'une clé. Pour Gradle, ~/.gradle est mis en cache ; pour CocoaPods — Pods/ ; pour npm/SPM — node_modules/.build. Lorsque le fichier de verrouillage change, le cache est automatiquement mis à jour. CircleCI prend en charge des politiques distinctes : save_cache peut être différé (when: always), tandis que restore_cache est obligatoire.

Le parallélisme combiné à la resource class permet d'ajuster finement les performances du build. Resource class détermine le nombre de CPU et la RAM pour un conteneur : small (1 CPU, 2 Go), medium (2 CPU, 4 Go), medium+ (3 CPU, 5 Go) et large (4 CPU, 8 Go). Pour les builds iOS avec Xcode, il est recommandé d'utiliser un exécuteur macOS avec une resource class medium ou larger — la compilation du code Swift nécessite des ressources importantes.

Le parallélisme répartit les tests sur plusieurs conteneurs, réduisant le temps d'exécution. Par exemple : parallelism: 4 exécute les tests dans 4 conteneurs parallèles. CircleCI distribue automatiquement les fichiers de test entre les conteneurs. La commande circleci tests glob collecte la liste des tests et circleci tests split les répartit uniformément.

Exemple de mise en cache Gradle

- restore_cache:
    keys:
      - v1-gradle-{{ checksum "build.gradle" }}
      - v1-gradle-

- run: ./gradlew assembleDebug

- save_cache:
    key: v1-gradle-{{ checksum "build.gradle" }}
    paths:
      - ~/.gradle/caches
      - ~/.gradle/wrapper

Exemple de configuration .circleci/config.yml

Examinons une configuration complète de CircleCI pour un projet Android avec deux jobs : build et test. La configuration comprend un exécuteur Docker avec Android SDK, la mise en cache de Gradle et l'exécution parallèle des tests. Les artifacts sont sauvegardés pour téléchargement. Le workflow build-and-test exécute les deux jobs à chaque push sur la branche principale.

version: 2.1

orbs:
  android: circleci/android@2.5.0

jobs:
  build:
    executor: android/default
    steps:
      - checkout
      - android/restore-gradle-cache
      - run: ./gradlew assembleRelease
      - android/save-gradle-cache
      - store_artifacts:
          path: app/build/outputs/apk/release
      - store_test_results:
          path: app/build/reports/tests

  test:
    executor: android/default
    parallelism: 4
    steps:
      - checkout
      - android/restore-gradle-cache
      - run:
          command: |
            cd app
            ./gradlew test

workflows:
  version: 2
  build-and-test:
    jobs:
      - build
      - test

Orbs : solutions CI/CD prêtes à l'emploi

Lors du choix entre CircleCI et les alternatives — si votre équipe utilise GitHub, GitHub Actions peut être un choix plus simple. CircleCI est préférable pour les équipes qui ont besoin d'une exécution parallèle flexible des tests, d'une configuration personnalisée de l'environnement d'exécution et de statistiques de build détaillées. CircleCI Insights fournit un tableau de bord avec des métriques de performance des pipelines : temps de build moyen, tendances et goulots d'étranglement. Insights aide à identifier les jobs de longue durée et à les optimiser. L'API CircleCI permet de gérer les pipelines par programmation, de déclencher des builds et d'obtenir des métriques.

Pour une gestion sécurisée des secrets, CircleCI prend en charge les Contexts — des ensembles nommés de variables d'environnement au niveau de l'organisation. Les Contexts sont protégés par un accès basé sur les rôles : seules certaines équipes peuvent utiliser un contexte particulier. Par exemple, le contexte production-deploy contient les clés App Store Connect et est accessible uniquement aux développeurs principaux. Combiné avec les approval gates, cela forme un système de sécurité CI/CD complet.

CircleCI Orb Registry contient des centaines de paquets prêts à l'emploi pour diverses tâches CI/CD. Pour le développement mobile, les orbs clés incluent : circleci/android, circleci/ios, circleci/flutter, laurencerussell/firebase-app-distribution. Chaque orb est versionné et documenté. Les orbs peuvent être publics (accessibles à tous) ou privés (uniquement pour votre organisation).

L'utilisation des orbs réduit la configuration de 5 à 10 fois. Par exemple, l'orb circleci/android fournit l'exécuteur android/default avec SDK préinstallé et les commandes restore-gradle-cache, save-gradle-cache. L'orb circleci/ios comprend un exécuteur avec Xcode et des commandes pour le code signing via fastlane. Les orbs peuvent être facilement combinés : ajoutez un orb android pour le build et un orb slack pour les notifications.

CircleCI offre également une prise en charge intégrée des rapports de test. Store_test_results analyse et visualise automatiquement les résultats de test aux formats JUnit, XCTest et autres. Pour les projets mobiles, cela signifie une visualisation centralisée des tests échoués, des tendances de temps d'exécution et de l'historique de stabilité des builds, simplifiant ainsi la maintenance de la qualité du code.

Exemple avec l'orb iOS

orbs:
  ios: circleci/ios@2.0.0

jobs:
  build-and-test:
    executor: ios/default
    steps:
      - checkout
      - ios/install-dependencies
      - ios/build-and-test

Publication d'un orb personnalisé est disponible via CircleCI CLI. Les commandes circleci orb create et circleci orb publish téléchargent l'orb dans le registre. Cela est utile pour standardiser le CI/CD au sein d'une organisation — créez une fois, utilisez dans tous les projets.