CI/CD - CI/CD (Intégration Continue et Déploiement / Livraison Continus)

Par Martin Fowler, Jez Humble & David Farley · 2006 (CI) / 2010 (CD - Continuous Delivery) · Sources officielles vérifiées

DevOps & CloudDonnée vérifiée & sourcéeDevOpsGitHub ActionsAutomatisationTestsGit

En résumé

Méthodologie DevOps automatisant le test, la validation et le déploiement du code à chaque modification dans un dépôt Git, garantissant la livraison rapide et sécurisée de versions fiables.

1. Définition détaillée & Contexte d'émergence

Le pipeline CI/CD constitue l'épine dorsale des équipes d'ingénierie modernes. L'Intégration Continue (CI) automatise l'exécution des linters, de la vérification de types et des tests unitaires/d'intégration à chaque commit ou Pull Request. La Livraison Continue (CD - Continuous Delivery) s'assure que le binaire est prêt à être publié en un clic, tandis que le Déploiement Continu (Continuous Deployment) pousse automatiquement le code validé en production sur les serveurs ou stores sans intervention humaine.

Pourquoi ce concept a été créé : Créé pour éradiquer le 'Merge Hell' où les développeurs passaient des jours à fusionner manuellement des branches de code divergentes avant des déploiements trimestriels anxiogènes.

2. Étapes d’un Pipeline CI/CD Typique

Un pipeline séquentiel où chaque étape conditionne le passage à la suivante.

1. Lint & Type-Check (Qualité)

Vérification statique rapide via ESLint, Prettier et `tsc --noEmit` pour détecter immédiatement les erreurs de syntaxe ou de contrat de types.

2. Automated Tests (Validation)

Exécution des tests unitaires (Vitest, Jest) et de bout en bout (Playwright, Cypress) dans des environnements conteneurisés éphémères.

3. Build & Release (Déploiement)

Génération des bundles optimisés, conteneurs Docker ou binaires mobiles (EAS Build), et déploiement progressif (Canary release ou Blue-Green) avec rollback automatique en cas d'anomalie.

3. Caractéristiques fondamentales

  • Exécution automatique à chaque push Git ou ouverture de Pull Request.
  • Détection immédiate des régressions avant la mise en production.
  • Environnements de prévisualisation éphémères (Preview Deployments Vercel).
  • Traçabilité totale des versions et déploiements audités.

5. Avantages et limites techniques

Points forts

  • ✓Confiance accrue des développeurs pour expédier du code en production plusieurs fois par jour.
  • ✓Résolution rapide des bugs grâce à des déploiements en petits incréments faciles à isoler.

Points de vigilance

  • ⚠Temps initial de configuration et maintenance des workflows (fichiers YAML).
  • ⚠Coûts de minutes de calcul de runners cloud sur les gros dépôts.

6. Recommandations : Quand l'utiliser ?

Idéal pour :

  • Tout projet collaboratif ou application en production.

À éviter pour :

  • Prototypage expérimental jetable d’une demi-journée.

8. Sources officielles vérifiées

Données techniques vérifiées auprès des documentations officielles, des RFCs et des spécifications standards.

Continuous Integration (Martin Fowler, 2006)martinfowler.com