Intégration continue (CI)

L’intégration continue (CI, continuous integration) signifie que les développeurs fusionnent fréquemment de petits changements dans la branche principale, et qu’un serveur compile le code et exécute les tests automatisés à chaque push ou pull request. L’objectif est un feedback rapide : si un changement casse quelque chose, son auteur le découvre tant que le changement est encore frais, et non des jours plus tard lors d’une grosse fusion.

Exemple (GitHub Actions)

Un pipeline minimal qui exécute la suite de tests à chaque pull request et à chaque push sur main :

name: CI
on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm test

Si npm test se termine avec un code non nul, le job échoue et la pull request affiche une coche rouge. Associé à une protection de branche qui exige ce contrôle, cela empêche de fusionner du code cassé.

Ce dont le testeur est responsable dans la CI

• Quels tests s’exécutent où. Tests unitaires et d’API rapides à chaque pull request ; suites end-to-end plus lentes à la fusion ou de manière planifiée. Un pipeline de pull request qui dure 40 minutes finit par ne plus être utilisé.
• La qualité du signal. Un test flaky dans un job bloquant habitue les gens à cliquer sur « re-run ». Mettez les tests instables en quarantaine pour qu’un build rouge ait toujours un sens.
• Les artefacts. Publiez rapports, traces et captures d’écran des exécutions en échec, pour que personne n’ait à reproduire un échec en local juste pour le voir.
• Le parallélisme. Répartir (sharding) une longue suite sur plusieurs machines maintient le temps de feedback stable à mesure que la suite grandit.

Différence avec le CD

La livraison continue (continuous delivery) prolonge la CI : chaque build qui passe est empaqueté et gardé prêt à être livré, généralement via des environnements de préproduction. Le déploiement continu (continuous deployment) va un cran plus loin et met automatiquement en production chaque changement validé. La CI est le socle des deux ; sans une suite de tests fiable à chaque commit, aucun des deux n’est sûr.

Erreurs courantes

Lancer la CI seulement la nuit, laisser la branche principale au rouge pendant des jours, et considérer le pipeline comme l’endroit où l’on écrit les tests plutôt que celui où on les exécute. La CI est une habitude d’équipe autant qu’un outil : de petites fusions, et corriger ou annuler (revert) dès que le build casse.