Prendre RDV
Lexique · DevOps / Cloud / Data

CI/CD : définition, pipeline et stratégies de déploiement

La chaîne d'automatisation qui teste, construit et met en production chaque modification de code : intégration continue, livraison et déploiement continus, pipeline type, stratégies de déploiement et exemple GitHub Actions.

Par Équipe Blent· Mis à jour le · 14 min de lecture· Niveau débutant

CI/CD en bref

Nom complet
Continuous Integration / Continuous Delivery
Composantes
Intégration, livraison et déploiement continus
Origine de la CI
Extreme Programming, fin des années 1990
Ouvrage de référence
Continuous Delivery, Humble et Farley, 2010
Outils phares
GitHub Actions, GitLab CI/CD, Jenkins
Unité d'exécution
Le pipeline, déclenché à chaque commit

Définition : CI/CD

La CI/CD désigne l'ensemble des pratiques et des outils qui automatisent le parcours d'une modification de code, de son intégration dans le dépôt jusqu'à sa mise en production. La CI, ou intégration continue, consiste à fusionner fréquemment le travail des développeurs et à le valider automatiquement par une compilation et des tests. La CD recouvre deux niveaux : la livraison continue, où chaque version validée est prête à être déployée sur décision humaine, et le déploiement continu, où elle part en production sans intervention. L'ensemble s'exécute dans un pipeline déclenché à chaque commit.

En une phrase : la CI/CD est la chaîne automatisée qui vérifie, construit et déploie chaque modification de code, du commit jusqu'à la production.

Dans cette définition

Qu'est-ce que la CI/CD ?

La CI/CD est la colonne vertébrale technique du DevOps : c'est elle qui rend possible la livraison fréquente et fiable que la culture DevOps vise.

Sans CI/CD, chaque développeur travaille longtemps sur sa branche, les fusions se font tardivement et douloureusement, et la mise en production suit une procédure manuelle de plusieurs pages. Chaque étape humaine est une occasion d'erreur, et chaque livraison regroupe tant de changements qu'il devient difficile d'identifier l'origine d'un problème. La CI/CD remplace ce processus par un pipeline automatique, exécuté à chaque modification, qui fournit en quelques minutes un verdict clair : la modification est-elle saine et peut-elle partir en production ?

L'intégration continue est née dans la communauté de l'Extreme Programming, à la fin des années 1990, et a été popularisée par un article de Martin Fowler. La livraison continue a été formalisée en 2010 par Jez Humble et David Farley dans leur livre Continuous Delivery. Les plateformes intégrées comme GitLab CI/CD puis GitHub Actions ont ensuite rendu ces pratiques accessibles à toutes les équipes, sans serveur dédié à administrer.

Aujourd'hui, une chaîne CI/CD construit le plus souvent une image Docker, la publie dans un registre, puis la déploie sur un orchestrateur de conteneurs ou un service Cloud managé.

À retenir : la CI garantit que le code reste toujours intégrable et testé ; la CD garantit qu'il reste toujours déployable, voire qu'il est déployé automatiquement.

Quelles sont les étapes d'un pipeline CI/CD ?

Un pipeline enchaîne des étapes automatiques, chacune pouvant arrêter la chaîne en cas d'échec. Le détail varie selon les projets, mais la plupart suivent la même structure.

  1. Déclencher

    Un push, l'ouverture d'une merge request ou la création d'un tag déclenche le pipeline. Le code est récupéré dans un environnement d'exécution propre et éphémère.

  2. Construire

    Les dépendances sont installées et le code compilé. Une erreur à ce stade est signalée en quelques minutes à l'auteur du commit.

  3. Tester

    Les tests unitaires puis d'intégration s'exécutent. Le linting et l'analyse de qualité vérifient le respect des conventions de l'équipe.

  4. Analyser la sécurité

    Analyse statique du code, audit des dépendances et détection de secrets repèrent les failles avant qu'elles n'atteignent un environnement.

  5. Packager

    Un artefact unique et versionné est produit, le plus souvent une image de conteneur, puis publié dans un registre. C'est lui qui sera déployé partout.

  6. Déployer en préproduction

    L'artefact est déployé dans un environnement proche de la production, où s'exécutent des tests de bout en bout ou de performance.

  7. Mettre en production

    Après validation manuelle (livraison continue) ou automatiquement (déploiement continu), l'artefact est déployé en production, souvent de manière progressive.

  8. Vérifier et revenir en arrière

    Des contrôles de santé et des métriques confirment le bon fonctionnement. En cas d'anomalie, la version précédente est restaurée automatiquement.

Intégration, livraison, déploiement continus : quelles différences ?

Les trois termes désignent trois niveaux d'automatisation successifs. Chacun suppose le précédent.

CritèreIntégration continueLivraison continueDéploiement continu
Ce qui est automatiséFusion, compilation et testsTout jusqu'à un artefact prêt à déployerTout, jusqu'à la production
Mise en productionHors périmètreDéclenchée par une décision humaineAutomatique après validation
PrérequisTests automatisés et fusions fréquentesEnvironnements reproductibles et déploiement scriptéTests très fiables, déploiement progressif, supervision
Fréquence typiquePlusieurs fois par jourÀ la demandeÀ chaque fusion validée
Contexte adaptéToutes les équipesLivraisons soumises à validationServices en ligne à fort rythme

Exemple concret : un workflow GitHub Actions

Voici un workflow GitHub Actions complet pour une API Python. À chaque pull request, il exécute les tests. À chaque fusion sur main, il construit et publie une image dans le registre de GitHub, puis la déploie sur Kubernetes avec Helm.

yaml
name: ci-cd

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
          cache: pip
      - run: pip install -r requirements.txt
      - run: pytest --maxfail=1

  build:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/acme/commandes-api:${{ github.sha }}

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment: production   # règles d'approbation configurables
    steps:
      - uses: actions/checkout@v4
      - name: Configurer l'accès au cluster
        run: |
          mkdir -p ~/.kube
          echo "${{ secrets.KUBECONFIG }}" > ~/.kube/config
      - name: Déployer avec Helm
        run: |
          helm upgrade --install commandes-api ./chart \
            --set image.tag=${{ github.sha }} \
            --wait --atomic

Quelques points clés. Le job build ne s'exécute que si les tests passent (needs: test) et uniquement sur la branche principale. L'image est étiquetée avec le SHA du commit, ce qui garantit que l'artefact déployé est exactement celui qui a été testé. L'environnement production peut exiger une approbation manuelle : le workflow passe alors de déploiement continu à livraison continue sans autre changement. Enfin, l'option --atomic de Helm annule automatiquement la mise à jour si les nouveaux pods ne démarrent pas.

Dans une approche GitOps, le job deploy serait remplacé par la mise à jour d'un dépôt de manifestes, appliquée ensuite par un agent installé dans le cluster. Et pour une chaîne plus sûre, on ajouterait des étapes d'analyse de sécurité, selon l'approche DevSecOps.

À quoi sert la CI/CD au quotidien ?

Une chaîne CI/CD s'applique à tout ce qui se décrit dans un dépôt Git, bien au-delà des applications web.

  • Applications web et API

    Tester et déployer chaque fonctionnalité dès qu'elle est fusionnée.

  • Microservices

    Donner à chaque service sa propre chaîne pour le livrer indépendamment des autres.

  • Applications mobiles

    Compiler, signer et publier les versions vers les magasins d'applications.

  • Infrastructure

    Valider et appliquer les changements Terraform ou Ansible avec la même rigueur que le code.

  • Modèles de machine learning

    Réentraîner, évaluer et déployer un modèle de façon reproductible, au cœur du MLOps.

  • Bibliothèques et documentation

    Publier automatiquement une nouvelle version d'un paquet ou d'un site à chaque tag.

Quels sont les avantages de la CI/CD ?

La CI/CD transforme la mise en production, autrefois un événement risqué, en une opération banale et répétable.

  • Erreurs détectées en quelques minutes, au moment où le contexte est encore frais pour le développeur.
  • Mises en production fréquentes et petites, donc plus faciles à comprendre et à annuler.
  • Processus de déploiement identique à chaque fois, sans étape manuelle oubliée.
  • Moins de conflits de fusion grâce à l'intégration quotidienne du travail de chacun.
  • Retour plus rapide des utilisateurs sur les nouvelles fonctionnalités.
  • Historique complet de ce qui a été testé, construit et déployé, et par qui.

Quelles sont les limites de la CI/CD ?

Une chaîne CI/CD ne vaut que par la qualité des tests et la discipline de l'équipe qui l'utilise.

  • Sans tests automatisés fiables, le pipeline déploie vite des régressions.
  • Tests instables qui échouent au hasard et finissent par être ignorés.
  • Pipelines lents qui découragent les commits fréquents et retardent les correctifs.
  • Maintenance continue des pipelines, des runners et des environnements de test.
  • Les identifiants détenus par la chaîne en font une cible de choix pour un attaquant.
  • Migrations de bases de données et dépendances entre services délicates à automatiser.

Les stratégies de déploiement : rolling, blue/green, canary

La dernière étape du pipeline, la mise en production, peut se faire de plusieurs façons. Le choix détermine l'exposition des utilisateurs à un éventuel problème et la rapidité du retour arrière.

StratégiePrincipeRetour arrièreCoût en ressources
RecreateArrêter l'ancienne version, puis démarrer la nouvelleRedéploiement, avec interruptionFaible
Rolling updateRemplacer les instances progressivement, une par uneProgressif, quelques minutesFaible
Blue/greenPréparer un environnement complet, puis basculer tout le traficInstantané, par rebasculeDouble pendant la bascule
CanaryExposer la nouvelle version à une petite part du trafic, puis élargirRapide, seule une fraction est touchéeModéré

Le déploiement blue/green privilégie la simplicité de la bascule et du retour arrière. Le déploiement canary va plus loin en mesurant le comportement de la nouvelle version sur du trafic réel avant de la généraliser, idéalement de façon automatique à partir des métriques d'erreur et de latence. Les feature flags complètent ces stratégies en dissociant le déploiement du code de l'activation d'une fonctionnalité.

GitHub Actions, GitLab CI ou Jenkins ?

Les trois outils dominent le marché, avec des logiques différentes.

  • GitHub Actions s'impose pour les projets hébergés sur GitHub. Ses workflows YAML s'appuient sur une vaste bibliothèque d'actions réutilisables, et les runners hébergés évitent toute infrastructure à gérer.
  • GitLab CI/CD est intégré nativement à GitLab, y compris en version auto-hébergée. Très apprécié des entreprises qui veulent garder leur code et leurs pipelines sur leur propre infrastructure, il propose aussi des fonctions de sécurité et de gestion des environnements.
  • Jenkins est le serveur d'automatisation open source historique, issu du projet Hudson. Extrêmement flexible grâce à ses plugins, il demande en contrepartie davantage d'administration.

Quel niveau d'automatisation viser ?

Toute équipe devrait pratiquer l'intégration continue. Aller jusqu'au déploiement continu dépend en revanche de la maturité des tests et du contexte métier.

Pertinent si

Visez le déploiement continu

  • Votre couverture de tests automatisés est solide et fiable.
  • Vos déploiements sont progressifs et le retour arrière est automatique.
  • Votre supervision détecte rapidement une dégradation.
  • Vous livrez un service en ligne que vous maîtrisez de bout en bout.
Moins adapté si

Restez en livraison continue

  • Une validation métier ou réglementaire est requise avant chaque mise en production.
  • Les mises en production doivent être coordonnées avec des clients ou des partenaires.
  • Vos tests ne couvrent pas encore les parcours critiques.
  • Vous livrez un logiciel installé chez les clients plutôt qu'un service en ligne.

Quels outils pour construire une chaîne CI/CD ?

Le marché se partage entre plateformes intégrées à l'hébergement du code, serveurs d'automatisation autonomes et outils spécialisés dans le déploiement.

Les concepts à connaître autour de la CI/CD

La CI/CD s'articule avec d'autres pratiques qui en conditionnent l'efficacité et la sécurité.

Ressources pour approfondir la CI/CD

Trois articles du blog Blent pour choisir ses outils et sécuriser ses mises en production.

Questions fréquentes

Questions fréquentes

CI signifie Continuous Integration, ou intégration continue. CD signifie selon le contexte Continuous Delivery (livraison continue) ou Continuous Deployment (déploiement continu). Le sigle CI/CD désigne l'ensemble de la chaîne, de la validation du code à sa mise en production.

Expertise

À propos de l'auteur

Équipe Blent

Les ingénieurs et mentors Blent conçoivent, automatisent et mettent en production des infrastructures Cloud, et forment chaque année des centaines de professionnels au Cloud et au DevOps.

Sources et méthodologie

  • Jez Humble, David Farley, Continuous Delivery, Addison-Wesley, 2010
  • Martin Fowler, Continuous Integration, martinfowler.com
  • Documentation officielle de GitHub Actions et de GitLab CI/CD
  • Retours d'expérience des projets et formations Blent
Lexique

Explorer le lexique

Voir toutes les définitions