03

⚡ Continuous Integration (CI)

Build, Test, Inspect - Automatiquement

"L'intégration continue est la ligne d'assemblage automatisée de l'usine logicielle. Finies les fusions de fin de mois qui cassent tout : on compile, on teste et on valide à chaque nouvelle ligne de code."

🏭 Analogie : L'Usine de Montage Automobile

La CI est comme une chaîne d'assemblage automatisée. Chaque fois qu'un ingénieur (développeur) ajoute une nouvelle pièce (commit), le tapis roulant s'active. Des robots intègrent la pièce au reste du châssis (build), puis des machines lui font subir des crash-tests (tests automatisés). Si la pièce ne s'adapte pas ou casse, l'alarme sonne et la chaîne s'arrête (pipeline failed) pour empêcher la production d'une voiture défectueuse.

⚠️ Rappel : La Règle d'Or de la CI

Briser le build n'est pas dramatique, le laisser cassé est un crime systémique. Si la CI échoue suite à votre commit, votre seule et unique priorité est de réparer (ou de revert) pour retrouver un état stable vert. Le code de la branche principale doit TOUJOURS être déployable.

📖 Pourquoi l'Intégration Continue (CI) ?

Avant le CI, le "jour de l'intégration" était redouté. On fusionnait des mois de code en une fois, créant des conflits massifs et des bugs indétectables. Le CI prône l'intégration fréquente (plusieurs fois par jour).

  • Fail Fast : Détecter les erreurs quelques minutes après le commit, pas des semaines plus tard.
  • Standardisation : Chaque commit est testé dans le même environnement (fini le "ça marche sur ma machine").
  • Qualité Constante : Le workflow impose des seuils de qualité (coverage, linting).
  • Confiance : La branche principale est toujours stable et "déployable".

💡 Le saviez-vous ? Le coût exponentiel des bugs

Réparer un bug détecté en Production coûte environ 100 fois plus cher que s'il est détecté pendant le développement (phase de CI).

  • Dev/CI : 1.000 € (Corrigé en 15 min)
  • Staging : 10.000 € (Mobilise QA + Repush)
  • Production : 100.000 € (Impact client, Hotfix express, Stress, réputation)

Le CI est votre meilleure assurance-vie technique.

🔄 A. Pipeline CI Typique

📥 Checkout Clone 📦 Install npm ci 🔨 Build Compile 🧪 Test Unit+E2E 🔍 Scan SAST/SCA

🛠️ B. Outils CI Populaires

Outil Hébergement Forces
GitHub Actions Cloud (GitHub / Self-hosted) Gratuit, intégré nativement, marketplace énorme, pipeline YAML complet.
GitLab CI Cloud / Self-hosted Extrêmement puissant, registry integré, "Auto DevOps", gestion fine des runners.
Jenkins Self-hosted (Principalement) Le dinosaure ultra-extensible (des milliers de plugins Groovy/Java). Lourd à maintenir.
CircleCI Cloud Performant, mise en cache agressive, très rapide sur les jobs parallélisés.

🐙 Deep-Dive: GitHub Actions (GHA)

GitHub Actions a révolutionné l'intégration continue en rapprochant au maximum le pipeline du code source. Vous n'avez plus besoin d'un serveur CI externe à maintenir. GHA est Event-Driven : il écoute des événements (push, release, issues) et déclenche des workflows orchestrant des machines virtuelles (les Runners).

1. 📡 Events

Ce qui déclenche le workflow. Exemples : push sur la branche main, création d'une pull_request, déclenchement temporel via schedule (cron), ou appel par API distante repository_dispatch.

2. 💻 Runners & Jobs

Un Runner est la VM qui exécute un Job (ex: ubuntu-latest). Les Jobs sont des ensembles de tâches qui s'exécutent naturellement en parallèle à moins que vous ne déclariez une dépendance explicite avec needs:.

3. 🚦 Steps & Actions

À l'intérieur d'un Job, on exécute des Steps en série (les unes après les autres). Une Step peut être une simple commande shell (run: make build) ou une Action packagée de la communauté (uses: actions/checkout@v4).

💻 Cas pratique réel : Pipeline CI Front-End Vif

Voici un workflow commenté pas-à-pas (à placer dans .github/workflows/ci.yml). Notez l'utilisation de actions/cache qui permet à ce pipeline de s'exécuter en moins d'une minute au lieu de cinq.

name: "Frontend CI Pipeline"

# 1. DÉCLENCHEURS : On limite aux branches utiles.
on:
  push:
    branches: [ "main", "develop" ]
  pull_request:

jobs:
  # NOM DU JOB
  build-and-test:
    # 2. RUNNER : Machine isolée et jetable (Ephémère).
    runs-on: ubuntu-latest
    
    # 3. ÉTAPES
    steps:
      - name: "🐙 Checkout du Code"
        uses: actions/checkout@v4
        # Télécharge magiquement le code de votre repo dans le runner

      - name: "⚙️ Setup Node.js (avec Cache NPM magique)"
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm' # Évite de re-télécharger l'internet entier à chaque PR

      - name: "📦 Clean Install"
        run: npm ci # "ci" = Clean Install. Refuse d'installer si package-lock est out-of-sync

      - name: "🔍 ESLint & Prettier (Analyse statique)"
        run: npm run lint

      - name: "🧪 Tests Unitaires & Couverture"
        run: npm test -- --coverage # Génère un rapport de couverture

      - name: "🛡️ Audit de Sécurité (Dépendances)"
        run: npm audit --audit-level=high

      - name: "🏗️ Build Production"
        run: npm run build # S'assure que le projet compile bel et bien

      - name: "📁 Upload Build Artifact"
        uses: actions/upload-artifact@v4
        with:
          name: dist-folder
          path: dist/
          retention-days: 7
          # L'artefact (.zip) sera disponible au téléchargement ou pour un autre job/repo CD !

⚡ Optimisations Radicales (GHA)

  • Matrix Strategy : Pour tester sur Node 18, 20 et 22 simultanément, GHA lance 3 runners parallèles automatiquement.
  • Path Filtering : Par exemple paths: ['src/**'] pour déclencher le job uniquement si le code source backend est touché, ignorant les README.
  • Concurrency : Annuler les vieux builds en cours via concurrency: cancel-in-progress lorsqu'un dev hard push sa branche 5 fois d'affilée.

✅ Best Practices Générales CI

  • Fast Feedback : Le pipeline doit s'exécuter en moins de 10 min (idéal < 5 min), sinon le développeur perd son contexte.
  • Fail Fast : Les étapes les plus rapides doivent être exécutées en premier (Linting avant Build, Build avant E2E).
  • No Flaky Tests : Les tests instables ("flaky") qui échouent au hasard détruisent la confiance des devs. À supprimer/isoler impitoyablement.
  • Pas de Secrets en clair : Utilisez obligatoirement ${{ secrets.API_KEY }}.

🔐 C. Security in CI (Shift-Left)

🔑

OIDC (OpenID Connect)

Fini les clés cloud AWS statiques commitées ! GHA assume un rôle IAM temporaire (1h) via OIDC pour communiquer avec votre cloud de manière totalement sécurisée.

🛡️

SAST & SCA

SAST (Analyse de code) et SCA (Dépendances). GitHub Dependabot scanne vos package.json ou Gemfile pour bloquer l'introduction de packages d'attaquants (Supply Chain Attack).

📜

SLSA & Signature

On signe cryptographiquement les artefacts de build (avec Sigstore/Cosign). Garantit au cluster prod que le binaire qu'il exécute vient exclusivement de votre CI.

🔄 À Retenir

  • Le but ultime est l'Honnêteté Technique Absolue : Un pipeline au rouge signifie que personne ne bouge avant qu'il ne soit de nouveau vert.
  • La CI ne remplace pas les tests locaux, elle garantit l'intégrité globale de l'arbre et produit des artefacts immutables pour la phase CD (Livraison).