IT Toolbox AI
CI/CD · Introduction

Introduction à CI/CD

Comprenez le cycle CI/CD, son vocabulaire et la différence entre livraison et déploiement continus.

Leçon disponible
20 min

Objectifs

  • Définir Continuous Integration, Continuous Delivery et Continuous Deployment.
  • Identifier repository, commit, pipeline, stage, job, runner, artifact et environment.
  • Lire un workflow CI/CD de bout en bout.
  • Situer Jenkins, GitLab CI/CD et GitHub Actions sans dépendre d’un fournisseur.

Introduction à CI/CD

CI signifie Continuous Integration, ou intégration continue. Les développeurs intègrent fréquemment de petits changements dans un repository ; une pipeline vérifie automatiquement le code avec un build, des tests et des contrôles de qualité.

CD peut signifier Continuous Delivery, livraison continue, ou Continuous Deployment, déploiement continu. Dans les deux cas, l’objectif est de rendre un changement validé déployable de manière fiable et répétable.

Le vocabulaire essentiel

Un repository conserve le code et son historique. Un commit représente un changement identifié. Une pipeline organise l’automatisation en stages, eux-mêmes composés de jobs exécutés par un runner ou agent.

  • repository : dépôt versionné contenant code, configuration et historique.
  • commit : instantané identifié d’un ensemble de changements.
  • pipeline : enchaînement automatisé de validations et d’actions.
  • stage : phase logique, par exemple build, test ou deploy.
  • job : unité de travail exécutée dans un stage.
  • runner/agent : machine ou environnement qui exécute le job.
  • artifact : résultat versionné du build destiné à être conservé ou déployé.
  • environment : contexte cible comme DEV, STAGING ou PROD.

Un workflow simple

Le push déclenche la CI. Si le build et les tests réussissent, un artifact est produit. La partie CD promeut ensuite cet artifact vers un environnement autorisé.

Du changement à la production
Developer
    ↓
Git Push
    ↓
CI
    ↓
Build
    ↓
Tests
    ↓
Artifact
    ↓
Deploy
    ↓
Production

Delivery ou Deployment ?

Avec Continuous Delivery, chaque version validée est prête à être déployée, mais une décision ou approbation peut déclencher le passage en production. Avec Continuous Deployment, chaque changement qui satisfait tous les contrôles est automatiquement déployé en production.

Le choix dépend du risque, de la réglementation, de la maturité des tests et de la capacité d’observation. Jenkins, GitLab CI/CD et GitHub Actions peuvent implémenter différents workflows ; les concepts restent indépendants de ces plateformes.

L’automatisation ne supprime pas la responsabilité : droits, approbations, surveillance et retour arrière restent adaptés à la criticité.

Mini résumé

  • La CI intègre et vérifie fréquemment les changements.
  • Continuous Delivery garde une décision de mise en production possible.
  • Continuous Deployment automatise aussi le passage en production après les contrôles.
  • Pipeline, stages, jobs, runners, artifacts et environments structurent le workflow.

Mini quiz

Trois questions pour vérifier les notions essentielles de la leçon.

1. Quel est l’objectif principal de la Continuous Integration ?
2. Quelle différence caractérise généralement Continuous Delivery ?
3. Quel composant exécute concrètement un job de pipeline ?