Principes CI/CD¶

Comprendre les trois niveaux de l'intégration et de la livraison continues, et pourquoi ils changent fondamentalement la façon de livrer du logiciel.

CI vs CD vs CD¶

Les trois sigles se ressemblent, mais ils désignent des pratiques distinctes avec des objectifs différents.

Intégration Continue (CI) : chaque modification de code est automatiquement vérifiée — build, tests, analyse statique. L'objectif est de détecter les régressions immédiatement, avant qu'elles ne s'accumulent.

Livraison Continue (Continuous Delivery) : le code passe CI et est automatiquement préparé pour être déployé en production. Le déploiement reste un acte humain volontaire, mais il peut être fait à tout moment en un clic.

Déploiement Continu (Continuous Deployment) : toute modification qui passe CI est automatiquement déployée en production sans intervention humaine.

graph LR
    A["Commit"] --> B["Build & Tests<br/>automatiques"]
    B --> C{"Qualite OK ?"}
    C -->|Non| D["Feedback<br/>immediat"]
    C -->|Oui| E["Artefact pret<br/>a deployer"]
    E --> F{"Declencheur"}
    F -->|"Manuel<br/>(CD Delivery)"| G["Production"]
    F -->|"Automatique<br/>(CD Deployment)"| G
    style D fill:#e74c3c,color:#fff
    style G fill:#2ecc71,color:#fff

Le feedback loop¶

La valeur de la CI repose sur la vitesse du retour d'information. Un pipeline qui prend 45 minutes est un pipeline que les développeurs ignorent.

Shift-left¶

Le principe shift-left consiste à détecter les problèmes le plus tôt possible dans le cycle de développement, là où le coût de correction est le plus bas.

graph LR
    A["Editeur<br/>secondes"] -->|"Linter + formatter"| B["Commit<br/>minutes"]
    B -->|"Pre-commit hooks"| C["Push CI<br/>< 10 min"]
    C -->|"Tests + SAST + SCA"| D["Staging<br/>heures"]
    D -->|"Tests E2E"| E["Production"]
    style A fill:#2ecc71,color:#fff
    style E fill:#e74c3c,color:#fff

Plus le problème est détecté à gauche, moins sa correction est chere. Un bug trouve dans l'éditeur se corrige en 30 secondes. Le même bug trouve en production peut mobiliser une équipe pendant des heures.

Principes fondamentaux¶

Reproductibilite¶

Le même commit doit produire exactement le même artefact, qu'il soit builde aujourd'hui, demain ou dans six mois. Cela implique :

• des dépendances versionnees et lockees (package-lock.json, requirements.txt)
• des images de base versionnees et non mutables (node:20.12.0 et non node:latest)
• un environnement de build défini (image conteneur reproductible)

Idempotence¶

Exécuter le pipeline une fois ou dix fois sur le même commit doit produire le même résultat. Les pipelines ne doivent pas avoir d'effets de bord cumulatifs.

Fail fast¶

Le pipeline doit échouer le plus tôt possible et avec un message clair. Ne pas continuer a construire une image si les tests ont échoué. Ne pas déployer si la signature est invalide.

Infrastructure as Code¶

L'environnement de CI lui-même est code. Les fichiers YAML de pipeline sont commites, versionnes, et soumis à revue comme le reste du code. Aucune configuration manuelle sur le serveur CI.

Le pipeline comme contrat¶

Un pipeline CI/CD bien conçu est un contrat passe avec l'équipe. Il garantit que tout code qui arrive en production :

Ce contrat sert aussi de documentation vivante : en lisant le pipeline, un nouveau développeur comprend exactement ce qu'il faut faire pour livrer du code.

Outils¶