Maîtriser les Monorepos : Optimisez votre Développement Web et Mobile
Maîtriser les Monorepos : Optimisez votre Développement Web et Mobile

Intégration et Déploiement Continus (CI/CD) dans un Monorepo

Bienvenue dans cette leçon dédiée à l'implémentation de l'Intégration et du Déploiement Continus (CI/CD) spécifiquement dans le contexte d'un monorepo. Après avoir exploré les avantages et les défis généraux des monorepos, il est crucial de comprendre comment orchestrer efficacement vos pipelines de développement pour maintenir la vélocité et la qualité lorsque de multiples applications et bibliothèques cohabitent dans un même dépôt.

Le CI/CD est la pierre angulaire du développement logiciel moderne, garantissant que votre code est toujours dans un état déployable. Dans un monorepo, cette tâche est à la fois plus complexe et potentiellement plus gratifiante, car elle permet une vision holistique et une synchronisation des efforts de développement. Préparez-vous à plonger dans les stratégies, les outils et les bonnes pratiques pour maîtriser le CI/CD dans votre monorepo.

1. Rappel des Fondamentaux du CI/CD

Avant de nous attaquer aux spécificités du monorepo, récapitulons les concepts clés du CI/CD.

Qu'est-ce que le CI/CD ?

Le CI/CD est un ensemble de pratiques qui automatisent les étapes du cycle de vie du développement logiciel, de l'intégration du code au déploiement.

  • Intégration Continue (CI) :

    • Définition : La pratique consistant à fusionner régulièrement les changements de code de plusieurs développeurs dans une branche principale partagée. Chaque fusion déclenche une série de tests automatisés (unitaires, d'intégration) et de builds.
    • Objectifs :
      • Détection précoce des erreurs : Les problèmes d'intégration sont identifiés et corrigés rapidement.
      • Feedback rapide : Les développeurs reçoivent un retour immédiat sur l'impact de leurs changements.
      • Réduction de la dette technique : Maintien d'une base de code saine.
      • Code toujours stable : La branche principale est toujours dans un état fonctionnel.

  • Déploiement Continu (CD) :

    • Définition : L'automatisation du déploiement de l'application dans un environnement de staging ou de production après que l'Intégration Continue a réussi. Le Déploiement Continu signifie que chaque changement qui passe toutes les étapes de CI est automatiquement déployé en production, tandis que la Livraison Continue signifie qu'il est prêt à être déployé en production à tout moment, mais qu'une intervention manuelle est requise pour le déclenchement final.
    • Objectifs :
      • Rapidité de mise sur le marché : Les nouvelles fonctionnalités sont livrées plus vite aux utilisateurs.
      • Fiabilité : Les processus automatisés réduisent les erreurs humaines.
      • Réduction des risques : Les déploiements fréquents et de petite taille sont moins risqués.
      • Optimisation des ressources : Libère les développeurs des tâches répétitives de déploiement.

Pourquoi le CI/CD est Essentiel ?

Le CI/CD est un pilier de la méthodologie DevOps et agile, car il :

  • Améliore la qualité du code en assurant des tests réguliers et un feedback rapide.
  • Accélère la livraison des fonctionnalités et des corrections de bugs.
  • Réduit les risques de régression et les pannes de production.
  • Favorise la collaboration et la visibilité au sein des équipes.
  • Libère du temps pour les développeurs, leur permettant de se concentrer sur l'innovation.

2. Les Spécificités du Monorepo pour le CI/CD

Les monorepos introduisent une couche de complexité, mais aussi des opportunités uniques, pour les pipelines CI/CD.

Rappel : Qu'est-ce qu'un Monorepo ?

Comme vu précédemment, un monorepo est un seul dépôt de code hébergeant le code de plusieurs projets, applications et bibliothèques distincts, mais potentiellement liés.

Ses avantages incluent :

  • Partage de code facilité : Les bibliothèques partagées sont simples à utiliser et à maintenir.
  • Changements atomiques : Une seule commit peut modifier plusieurs projets interconnectés, garantissant la cohérence.
  • Visibilité et cohérence : Une vue d'ensemble sur l'ensemble du système et des outils/configurations unifiés.

Les Défis du CI/CD en Monorepo

L'un des plus grands défis d'un monorepo est la gestion des pipelines CI/CD de manière efficace :

  • Builds et Tests Non Nécessaires : Le risque majeur est de reconstruire et de tester tout le monorepo à chaque petit changement. Si un développeur modifie une seule ligne dans une application front-end, il n'est pas nécessaire de reconstruire le microservice de paiement ou l'application mobile. Cela entraînerait des temps de pipeline excessivement longs et un gaspillage de ressources.

  • Dépendances Complexes : Les projets au sein d'un monorepo peuvent avoir des dépendances internes et externes complexes. S'assurer que les changements dans une bibliothèque partagée déclenchent les builds et tests appropriés dans tous les projets qui en dépendent est crucial et délicat.

  • Gestion des Versions et Déploiements Indépendants : Bien que dans un monorepo, les applications sont souvent versionnées et déployées indépendamment. Votre pipeline CI/CD doit être capable de gérer ces cycles de vie distincts sans affecter les autres projets.

  • Performance : Les grands monorepos peuvent contenir des centaines de projets. L'exécution de toutes les étapes CI/CD pour chaque changement peut rapidement devenir un goulot d'étranglement.

Les Avantages du CI/CD en Monorepo

Malgré les défis, un CI/CD bien orchestré dans un monorepo offre des avantages significatifs :

  • Visibilité Accrue : Les pipelines centralisés offrent une vue claire de l'état de tous les projets.
  • Cohérence des Outils et Configurations : Il est plus facile d'uniformiser les outils, les scripts et les configurations CI/CD pour l'ensemble du dépôt.
  • Refactoring Facilité : Lorsqu'une bibliothèque partagée est refactorisée, le pipeline CI/CD peut immédiatement tester l'impact sur tous les projets dépendants, simplifiant le processus.
  • Déploiements Coordonnés : Pour les changements qui affectent plusieurs services, un monorepo permet des commits atomiques et des déploiements potentiellement coordonnés.

3. Stratégies et Outils pour le CI/CD en Monorepo

Pour relever les défis du CI/CD en monorepo, plusieurs stratégies et outils sont essentiels.

1. Détection des Changements (Change Detection)

C'est la stratégie la plus critique. L'objectif est de n'exécuter les étapes de build, test et déploiement que pour les projets réellement affectés par un changement.

  • Concept : Utiliser un système intelligent pour identifier quels fichiers ont été modifiés dans une commit ou une pull request et, à partir de là, déterminer quels projets (applications ou bibliothèques) sont impactés.

  • Comment l'implémenter ?

    • Outils de Monorepo (Nx, Turborepo) : Ces outils sont conçus pour cela. Ils construisent un graphe de dépendances de votre monorepo et peuvent déterminer avec précision les projets affectés par un changement, y compris les dépendances transitives. Ils offrent des commandes comme nx affected:build ou turbo run build --filter="[<scope>]"
    • Logique Custom dans le Pipeline (Git) : Pour des monorepos plus simples ou si vous n'utilisez pas d'outils dédiés, vous pouvez utiliser des commandes Git pour détecter les fichiers modifiés et écrire une logique conditionnelle dans votre pipeline.

Exemple de Détection de Changements avec Git (Bash)

Cet exemple montre comment un script Bash pourrait identifier les applications et bibliothèques modifiées dans un monorepo.

#!/bin/bash

# Ce script détecte les applications et librairies modifiées
# dans un monorepo par rapport à une branche de base (ex: main).
# Utile pour conditionner les builds et tests dans un pipeline CI/CD.

# Structure du monorepo supposée:
# monorepo/
# ├── apps/
# │   ├── app1/
# │   └── app2/
# └── packages/
#     ├── lib1/
#     └── lib2/

# Détecter les fichiers modifiés entre la branche actuelle et la branche de base (ex: main)
# Pour une PR, 'git merge-base main HEAD' donne le point de divergence commun.
# Pour un push sur main, on pourrait comparer avec HEAD~1 ou une version précédente.
# Ici, nous utilisons une base de fusion pour les PR, et HEAD~1 pour les pushes simples.
if [ -n "$GITHUB_BASE_REF" ]; then # Ex: dans GitHub Actions pour une PR
  BASE_COMMIT=$(git merge-base "$GITHUB_BASE_REF" HEAD)
else
  BASE_COMMIT="HEAD~1" # Ou HEAD^ pour le parent direct du dernier commit
fi

echo "Comparaison avec la base: $BASE_COMMIT"
AFFECTED_FILES=$(git diff --name-only "$BASE_COMMIT" HEAD)

# Initialisation des tableaux pour stocker les noms des projets affectés
declare -a AFFECTED_APPS
declare -a AFFECTED_LIBS

echo "Fichiers modifiés :"
echo "$AFFECTED_FILES"
echo "---"

# Parcourir chaque fichier modifié et identifier le projet parent
for FILE in $AFFECTED_FILES; do
  if [[ "$FILE" =~ ^apps/([^/]+)/ ]]; then
    APP_NAME=${BASH_REMATCH[1]}
    # Ajouter à la liste si non déjà présent
    if [[ ! " ${AFFECTED_APPS[@]} " =~ " ${APP_NAME} " ]]; then
      AFFECTED_APPS+=("$APP_NAME")
    fi
  elif [[ "$FILE" =~ ^packages/([^/]+)/ ]]; then
    LIB_NAME=${BASH_REMATCH[1]}
    if [[ ! " ${AFFECTED_LIBS[@]} " =~ " ${LIB_NAME} " ]]; then
      AFFECTED_LIBS+=("$LIB_NAME")
    fi
  fi
done

echo "Applications affectées: ${AFFECTED_APPS[@]}"
echo "Librairies affectées: ${AFFECTED_LIBS[@]}"
echo "---"

# Exemple d'utilisation: déclencher des actions spécifiques
if [[ " ${AFFECTED_APPS[@]} " =~ "app1" ]]; then
  echo "--- Démarrage des tâches pour 'app1' ---"
  # cd apps/app1 && npm test && npm run build
  # Par exemple, pour GitHub Actions, on pourrait définir des sorties:
  # echo "APP1_CHANGED=true" >> "$GITHUB_OUTPUT"
fi

if [[ " ${AFFECTED_LIBS[@]} " =~ "lib1" ]]; then
  echo "--- Démarrage des tâches pour 'lib1' et ses dépendants ---"
  # Ici, il faudrait aussi identifier les applications dépendant de lib1
  # et déclencher leurs builds/tests. Les outils monorepo comme Nx le font automatiquement.
fi

# Pour les systèmes CI/CD, vous pouvez retourner ces listes ou définir des variables d'environnement.
# Par exemple, pour GitHub Actions:
# echo "AFFECTED_APPS=$(IFS=,; echo "${AFFECTED_APPS[*]}")" >> "$GITHUB_ENV"
# echo "AFFECTED_LIBS=$(IFS=,; echo "${AFFECTED_LIBS[*]}")" >> "$GITHUB_ENV"

Explication du code : Ce script Bash utilise git diff --name-only pour obtenir la liste des fichiers modifiés entre deux commits (souvent le HEAD de votre branche et le HEAD de la branche main ou master ou le merge-base pour une PR). Il parcourt ensuite cette liste et, grâce à des expressions régulières, identifie le nom du projet (application ou bibliothèque) auquel appartient chaque fichier modifié. Enfin, il affiche les listes des projets affectés, ce qui pourrait ensuite être utilisé par votre système CI/CD pour conditionner l'exécution de jobs spécifiques. Pour une intégration dans des plateformes comme GitHub Actions, les résultats peuvent être passés via les outputs ou environnement variables.

2. Cache Distribué (Distributed Caching)

Même avec une détection intelligente des changements, certaines tâches doivent être exécutées. Le cache distribué permet de stocker les résultats de builds et de tests (artefacts, node_modules installés, etc.) pour qu'ils puissent être réutilisés lors de futures exécutions, même sur des agents de CI différents.

  • Comment l'implémenter ?
    • Outils de Monorepo : Nx et Turborepo incluent un cache local et distant qui stocke les sorties de chaque tâche (build, test). Si une tâche a déjà été exécutée avec les mêmes entrées, le résultat mis en cache est récupéré instantanément.
    • Fournisseurs de CI/CD : La plupart des plateformes (GitHub Actions, GitLab CI, CircleCI) offrent des fonctionnalités de cache pour les dépendances (node_modules), permettant de gagner un temps considérable.

3. Exécution Parallèle (Parallel Execution)

Lorsque plusieurs projets doivent être construits ou testés, il est souvent possible d'exécuter ces tâches en parallèle pour réduire le temps total du pipeline.

  • Comment l'implémenter ?
    • Configuration des Runners de CI/CD : Les plateformes CI/CD permettent souvent de définir des jobs indépendants qui peuvent s'exécuter simultanément sur différents agents.
    • Outils de Monorepo : Nx et Turborepo peuvent paralléliser automatiquement les tâches basées sur le graphe de dépendances, exécutant en parallèle toutes les tâches qui n'ont pas de dépendances intermédiaires non résolues.

4. Configuration des Pipelines

La configuration de votre fichier CI/CD doit être flexible et intelligente pour gérer le monorepo.

  • Granularité : Vous pouvez avoir :
    • Une configuration de pipeline unique et centrale pour tout le monorepo, utilisant des conditions basées sur la détection des changements.
    • Des configurations de pipeline par projet, si votre système CI/CD le permet (ex: Gitlab CI avec include: et rules:changes).
  • Utilisation des paths ou changes : La plupart des systèmes CI/CD modernes permettent de déclencher des jobs spécifiques uniquement si certains chemins de fichiers ont été modifiés.

Exemple de Configuration CI/CD (GitHub Actions)

Voici un exemple simplifié d'un workflow GitHub Actions qui utilise la détection de changements conceptuelle pour conditionner l'exécution des jobs.

# .github/workflows/ci-monorepo.yml
name: CI/CD Monorepo Example

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  # Job pour détecter les changements dans les projets
  detect-monorepo-changes:
    runs-on: ubuntu-latest
    outputs:
      # Les sorties peuvent être consommées par d'autres jobs
      app1_changed: ${{ steps.check_app1.outputs.changed }}
      app2_changed: ${{ steps.check_app2.outputs.changed }}
      lib1_changed: ${{ steps.check_lib1.outputs.changed }}
    steps:
      - uses: actions/checkout@v3

      # Étape pour détecter les changements dans 'apps/app1'
      # En production, vous utiliseriez un script comme celui présenté précédemment,
      # ou une action GitHub spécialisée (ex: tj-actions/changed-files)
      # ou un outil monorepo (Nx, Turborepo)
      - name: Check for changes in app1
        id: check_app1
        run: |
          # Simulation: si le fichier "apps/app1/src/index.ts" a été modifié
          # Remplacez par une logique réelle de git diff ou un outil monorepo
          if git diff --name-only ${{ github.event.before }} ${{ github.sha }} | grep -q "apps/app1/"; then
            echo "changed=true" >> "$GITHUB_OUTPUT"
          else
            echo "changed=false" >> "$GITHUB_OUTPUT"
          fi

      - name: Check for changes in app2
        id: check_app2
        run: |
          if git diff --name-only ${{ github.event.before }} ${{ github.sha }} | grep -q "apps/app2/"; then
            echo "changed=true" >> "$GITHUB_OUTPUT"
          else
            echo "changed=false" >> "$GITHUB_OUTPUT"
          fi

      - name: Check for changes in lib1
        id: check_lib1
        run: |
          if git diff --name-only ${{ github.event.before }} ${{ github.sha }} | grep -q "packages/lib1/"; then
            echo "changed=true" >> "$GITHUB_OUTPUT"
          else
            echo "changed=false" >> "$GITHUB_OUTPUT"
          fi

  # Job de build et test pour 'app1'
  build-test-app1:
    needs: detect-monorepo-changes # Ce job dépend du job de détection
    if: needs.detect-monorerepo-changes.outputs.app1_changed == 'true'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Install dependencies (root)
        run: npm install # Installer les dépendances globales du monorepo
      - name: Install app1 dependencies
        working-directory: apps/app1
        run: npm ci # Utilise npm ci pour une installation propre
      - name: Build app1
        working-directory: apps/app1
        run: npm run build
      - name: Test app1
        working-directory: apps/app1
        run: npm test

  # Job de build et test pour 'app2'
  build-test-app2:
    needs: detect-monorepo-changes
    if: needs.detect-monorerepo-changes.outputs.app2_changed == 'true'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - name: Install dependencies (root)
        run: npm install
      - name: Install app2 dependencies
        working-directory: apps/app2
        run: npm ci
      - name: Build app2
        working-directory: apps/app2
        run: npm run build
      - name: Test app2
        working-directory: apps/app2
        run: npm test

  # Job de déploiement pour 'app1' (dépend du succès du build/test et des changements)
  deploy-app1:
    needs: [build-test-app1, detect-monorepo-changes]
    if: needs.detect-monorerepo-changes.outputs.app1_changed == 'true' && needs.build-test-app1.result == 'success' && github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy App1
        run: echo "Déploiement de app1 vers la production..."
        # Ajoutez ici vos commandes de déploiement (ex: aws s3 sync, gcloud deploy, vercel deploy)

Explication du code : Ce workflow GitHub Actions illustre comment structurer un pipeline CI/CD pour un monorepo.

  1. Un premier job (detect-monorepo-changes) est responsable de détecter quels projets ont été modifiés. Il utilise un id pour stocker les résultats (app1_changed, app2_changed, etc.) comme des outputs. Pour une détection plus sophistiquée, vous intégreriez ici le script Bash précédent ou un outil monorepo.
  2. Des jobs subséquents (build-test-app1, build-test-app2) dépendent du job de détection (needs: detect-monorepo-changes).
  3. La condition if: needs.detect-monorepo-changes.outputs.app1_changed == 'true' garantit que le job ne s'exécutera que si des changements ont été détectés dans app1.
  4. L'attribut working-directory est crucial pour exécuter les commandes npm ou autres dans le contexte du projet spécifique au sein du monorepo.
  5. Des jobs de déploiement peuvent être ajoutés, dépendant à la fois de la détection de changements et du succès des étapes de build/test correspondantes.

Cette approche, bien que fonctionnelle, peut devenir répétitive et difficile à maintenir avec un grand nombre de projets. C'est pourquoi les outils dédiés aux monorepos sont si précieux.

5. Outils Spécifiques aux Monorepos (Lerna, Nx, Turborepo)

Ces outils ont été conçus pour simplifier la gestion des monorepos, y compris leurs pipelines CI/CD :

  • Nx (Nrwl Extensible) : Un système de build intelligent pour monorepos. Il construit un graphe de dépendances précis de votre espace de travail.

    • Détection des changements : Peut identifier avec précision les projets affectés par un changement (nx affected:lint, nx affected:test, nx affected:build).
    • Exécution intelligente : N'exécute les tâches que pour les projets affectés et leurs dépendances.
    • Cache distribué : Met en cache les résultats des tâches et peut les partager localement ou à distance pour accélérer les pipelines.
    • Exécution parallèle : Parallélise automatiquement les tâches qui peuvent l'être.

  • Turborepo : Un système de build haute performance et incrémental pour les monorepos JavaScript/TypeScript.

    • Fast Incremental Builds : Ne rebuild que ce qui est nécessaire.
    • Remote Caching : Partage les caches de build avec les membres de l'équipe et les pipelines CI/CD.
    • Pruning : Permet d'extraire une sous-partie de votre monorepo pour des déploiements plus efficaces.

  • Lerna : Plus orienté sur la gestion des paquets npm au sein d'un monorepo. Il aide à gérer le versioning et la publication de plusieurs paquets depuis un seul dépôt Git. Bien qu'il ne soit pas un système de build à part entière comme Nx ou Turborepo, il peut être utilisé en combinaison avec eux ou avec des scripts CI/CD pour gérer les paquets individuels.

Ces outils réduisent considérablement la complexité des configurations CI/CD, permettant aux développeurs de se concentrer sur le code plutôt que sur l'orchestration des pipelines.

4. Bonnes Pratiques et Conseils

Pour maximiser l'efficacité de votre CI/CD en monorepo :

  • Structure de Répertoire Claire : Organisez votre monorepo de manière logique (ex: apps/ pour les applications, packages/ ou libs/ pour les bibliothèques partagées). Cela facilite la détection des changements et la maintenance.
  • Granularité des Tests : Assurez-vous que chaque projet a ses propres tests unitaires et d'intégration ciblés. Les tests de bout en bout (E2E) peuvent être plus complexes à gérer dans un monorepo et doivent être soigneusement orchestrés.
  • Environnements Indépendants : Chaque application au sein du monorepo doit pouvoir être construite, testée et déployée indépendamment des autres, avec ses propres variables d'environnement et configurations.
  • Gestion des Dépendances : Utilisez un gestionnaire de dépendances (npm, yarn, pnpm) au niveau de la racine du monorepo pour gérer les dépendances communes, et spécifiez les dépendances spécifiques à chaque projet dans leurs package.json respectifs.
  • Monitoring et Alerting : Mettez en place un système de monitoring pour vos pipelines CI/CD. Recevez des alertes en cas d'échec de build ou de déploiement pour réagir rapidement.
  • Documentation : Documentez clairement la stratégie CI/CD de votre monorepo, y compris la logique de détection des changements, les outils utilisés et les procédures de déploiement pour chaque projet.
  • Itération et Optimisation : Commencez avec une stratégie CI/CD fonctionnelle mais simple, puis itérez. Mesurez les temps de pipeline, identifiez les goulots d'étranglement et introduisez progressivement des optimisations (comme le cache distribué ou l'exécution parallèle plus poussée).

Conclusion

L'intégration et le déploiement continus sont plus qu'une simple commodité ; ils sont une nécessité pour maintenir l'agilité et la qualité dans tout environnement de développement moderne, et ce n'est pas différent pour un monorepo.

Nous avons vu que les monorepos présentent des défis uniques en matière de CI/CD, principalement liés à la taille et à l'interdépendance des projets. Cependant, en adoptant des stratégies clés telles que la détection intelligente des changements, l'utilisation judicieuse du cache et l'exécution parallèle, et en tirant parti d'outils spécifiques aux monorepos comme Nx ou Turborepo, il est tout à fait possible de bâtir des pipelines CI/CD performants et robustes.

Un CI/CD bien pensé dans un monorepo vous permettra non seulement d'accélérer la livraison de vos fonctionnalités, mais aussi de renforcer la collaboration entre vos équipes, de garantir la cohérence de votre codebase et de réduire les risques de régression. C'est un investissement qui portera ses fruits en termes de productivité et de sérénité pour votre développement web et mobile.