Lance-toi en CI CD Pipeline : ton premier pas concret aujourd'hui

CI CD Pipeline : l'essentiel en un article — vrai code, schémas et étapes concrètes, extraits d'un cours de 20 leçons.

Lance-toi en CI CD Pipeline : ton premier pas concret aujourd'hui

La meilleure façon d'apprendre CI CD Pipeline, c'est de faire. Cet article te met le pied à l'étrier avec des extraits pratiques tirés d'un cours de 20 leçons — de quoi obtenir un premier résultat dès aujourd'hui.

tl;dr
  • Introduction au CICD
  • Integration Continue
  • Qualite du Code
  • Optimisation du Pipeline
  • Deploiement Continu
~$ cat ./parcours.md # CI CD Pipeline — 6 chapitres
01
Introduction au CICD
→ Chapitre 00.1 — Philosophie CI/CD : Pourquoi automatiser ?→ Chapitre 00.2 — L'écosystème des outils CI/CD+ 1 autres leçons
02
Intégration Continue
→ Chapitre 01.1 — Stratégies de branches Git→ Chapitre 01.2 — Builds automatisés et pipelines YAML avancés+ 1 autres leçons
03
Qualité du Code
→ Chapitre 02.1 — Analyse statique avec SonarQube→ Chapitre 02.2 — Sécurité dans le CI/CD : SAST, DAST et dépendances+ 1 autres leçons
04
Optimisation du Pipeline
→ Chapitre 03.1 — Optimisation du Pipeline : Cache, Parallélisation et Matrices→ Chapitre 03.2 — Optimisation des builds Docker+ 1 autres leçons
05
Déploiement Continu
→ Chapitre 04.1 — Stratégies de déploiement avancées→ Chapitre 04.2 — Environnements, Secrets et Rollback+ 1 autres leçons
06
Monitoring et Observabilité
→ Chapitre 05.1 — Monitoring et Observabilité post-déploiement→ Chapitre 05.2 — SLO, SLA et Métriques DORA
🏁
Projet final
→ Tu repars avec un projet concret et démontrable

Code Coverage et seuils de qualité

Chapitre 02 • Leçon 03 • Durée : 45 min

NOTE🎯 Objectifs
  • Comprendre ce qu'est le code coverage et ses limites
  • Mesurer la couverture avec les outils standard (pytest-cov, jest, JaCoCo)
  • Définir des seuils intelligents (line, branch, mutation)
  • Bloquer un PR si la coverage chute
  • Visualiser les rapports dans Codecov ou SonarQube

1. Qu'est-ce que le code coverage ?

La couverture de code mesure le pourcentage de lignes (ou de branches, conditions, fonctions) exécutées par vos tests automatisés.

TypeMesureExemple
Line Coverage% de lignes exécutées80 % = 80 lignes sur 100 sont touchées
Branch Coverage% de branches conditionnelles testéesif/else, switch — les 2 chemins doivent passer
Function Coverage% de fonctions appeléesToutes les fonctions exportées sont-elles testées ?
Statement Coverage% d'instructions exécutéesProche du line coverage
Mutation Coverage% de mutations détectées par les testsPlus fiable mais coûteux (mutation testing)
WARNING⚠️ Piège classique

100 % de couverture ne signifie PAS 100 % de qualité. On peut avoir 100 % de lignes exécutées sans vérifier les résultats. assert est tout aussi important que d'exécuter le code.

2. Coverage en Python avec pytest-cov

output
pip install pytest pytest-cov

# Lancer les tests avec coverage
pytest --cov=mon_module --cov-report=term --cov-report=html

# Sortie console :
# Name            Stmts   Miss  Cover
# -------------------------------------
# mon_module.py     50      5    90%
# -------------------------------------
# TOTAL             50      5    90%

# Rapport HTML interactif dans htmlcov/index.html

Configuration via pyproject.toml

output
[tool.pytest.ini_options]
addopts = "--cov=src --cov-report=term-missing --cov-report=xml --cov-fail-under=80"

[tool.coverage.run]
source = ["src"]
omit = [
    "*/tests/*",
    "*/migrations/*",
    "*/__init__.py"
]

[tool.coverage.report]
exclude_lines = [
    "pragma: no cover",
    "raise NotImplementedError",
    "if __name__ == .__main__.:",
]
fail_under = 80
show_missing = true

3. Coverage en JavaScript avec Jest

output
npm install --save-dev jest

# package.json
{
  "scripts": {
    "test": "jest",
    "test:coverage": "jest --coverage"
  },
  "jest": {
    "collectCoverageFrom": [
      "src/**/*.{js,ts}",
      "!src/**/*.d.ts",
      "!src/index.ts"
    ],
    "coverageThreshold": {
      "global": {
        "branches": 75,
        "functions": 80,
        "lines": 80,
        "statements": 80
      }
    },
    "coverageReporters": ["text", "lcov", "html", "cobertura"]
  }
}

# Lancer
npm run test:coverage

# Si seuil non atteint :
# Jest: "global" coverage threshold for lines (80%) not met: 73.5%
# → Build ÉCHOUE

4. Coverage en Java avec JaCoCo

output
<!-- pom.xml -->
<plugin>
  <groupId>org.jacoco</groupId>
  <artifactId>jacoco-maven-plugin</artifactId>
  <version>0.8.11</version>
  <executions>
    <execution>
      <goals><goal>prepare-agent</goal></goals>
    </execution>
    <execution>
      <id>report</id>
      <phase>test</phase>
      <goals><goal>report</goal></goals>
    </execution>
    <execution>
      <id>jacoco-check</id>
      <goals><goal>check</goal></goals>
      <configuration>
        <rules>
          <rule>
            <element>BUNDLE</element>
            <limits>
              <limit>
                <counter>LINE</counter>
                <value>COVEREDRATIO</value>
                <minimum>0.80</minimum>
              </limit>
            </limits>
          </rule>
        </rules>
      </configuration>
    </execution>
  </executions>
</plugin>

mvn clean test
# Rapport dans target/site/jacoco/index.html

5. Définir des seuils intelligents

Type de projetSeuil recommandé
Critical (banking, healthcare, aerospace)90-95 %
SaaS / Web app production80-85 %
Backend API75-85 %
Frontend (UI logic)60-70 %
Prototype / MVP40-60 %
Script utilitaire0-30 % (souvent inutile)
TIP💡 Stratégie réaliste

Plutôt qu'un seuil absolu, exigez que la coverage ne baisse pas par rapport à la branche main. Codecov et SonarQube font ça nativement.

6. Intégration GitHub Actions

output
name: CI with Coverage

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'
      
      - name: Install
        run: pip install -e ".[dev]"
      
      - name: Tests + coverage
        run: pytest --cov --cov-report=xml --cov-report=term --cov-fail-under=80
      
      - name: Upload coverage to Codecov
        uses: codecov/codecov-action@v4
        with:
          file: ./coverage.xml
          token: ${{ secrets.CODECOV_TOKEN }}
          fail_ci_if_error: true

7. Codecov : visualiser et comparer

codecov.yml pour personnaliser

output
coverage:
  status:
    project:
      default:
        target: 80%
        threshold: 1%
    patch:
      default:
        target: 90%
        threshold: 5%

comment:
  layout: "header, diff, flags, files"
  behavior: default
  require_changes: false

ignore:
  - "tests/**"
  - "**/__init__.py"
  - "migrations/**"

Gestion des artifacts et registries

Chapitre 03 • Leçon 03 • Durée : 45 min

NOTE🎯 Objectifs
  • Comprendre ce qu'est un artifact et un registry
  • Stocker et partager des artifacts (zip, jar, wheel) dans GitHub Actions
  • Pusher des images Docker vers Docker Hub, GHCR, AWS ECR
  • Gérer le versioning sémantique des artifacts
  • Mettre en place des règles de rétention pour éviter l'explosion des coûts

1. Qu'est-ce qu'un artifact ?

Un artifact est tout fichier produit par un build et destiné à être utilisé plus tard :

Type d'artifactExempleRegistry typique
Image containerdevforge-api:1.2.3 (Docker)Docker Hub, GHCR, ECR, Quay
Package Pythonmy-lib-1.0.0.whlPyPI, AWS CodeArtifact, GitHub Packages
Package npmmy-lib-1.0.0.tgznpm registry, GitHub Packages
JAR Javamy-app-1.0.jarMaven Central, Nexus, JFrog Artifactory
Binaire compilémy-cli-linux-amd64GitHub Releases, S3
Helm chartmy-chart-1.0.0.tgzChartMuseum, OCI registries
Fichier ZIP génériquebuild-output.zipGitHub Actions Artifacts, S3

2. Artifacts GitHub Actions (intra-workflow)

Uploader un artifact

output
- name: Build wheel
  run: python -m build

- name: Upload wheel as artifact
  uses: actions/upload-artifact@v4
  with:
    name: python-wheel
    path: dist/*.whl
    retention-days: 30

Télécharger dans un job suivant

output
deploy:
  needs: build
  runs-on: ubuntu-latest
  steps:
    - name: Download wheel
      uses: actions/download-artifact@v4
      with:
        name: python-wheel
        path: ./dist
    
    - name: Install
      run: pip install dist/*.whl
TIP

Les artifacts GitHub sont gratuits jusqu'à 500 Mo par repo public, et expirent par défaut après 90 jours.

3. Container registries comparés

RegistryCoûtAvantagesInconvénients
Docker HubGratuit (public) / 5 $/user (private)Le plus populaire, large ecosystemRate limits sur les pulls
GHCR (GitHub)Gratuit (public) / inclus GitHubIntégration GitHub nativeMoins connu
AWS ECR0.10 $/Go/moisSécurité IAM, scan auto, intégré ECS/EKSRégion-spécifique
GCR / Artifact Registry0.10 $/Go/moisIntégré GCP, multi-formatLock-in GCP
Azure ACRBasic 5 $/moisIntégré AzureLock-in Azure
Quay.ioGratuit (public) / payant (private)Détecteur de vulnérabilités fortMoins de support
Harbor (self-hosted)Gratuit (mais ops)Sans dépendance externe, full controlÀ maintenir vous-même

4. Push vers Docker Hub depuis GitHub Actions

output
- name: Login Docker Hub
  uses: docker/login-action@v3
  with:
    username: ${{ secrets.DOCKERHUB_USERNAME }}
    password: ${{ secrets.DOCKERHUB_TOKEN }}

- name: Build and push
  uses: docker/build-push-action@v5
  with:
    context: .
    push: true
    tags: |
      myuser/myapp:latest
      myuser/myapp:${{ github.sha }}
      myuser/myapp:${{ github.ref_name }}
    platforms: linux/amd64,linux/arm64
    cache-from: type=gha
    cache-to: type=gha,mode=max

5. Push vers GHCR (GitHub Container Registry)

output
- name: Login to GHCR
  uses: docker/login-action@v3
  with:
    registry: ghcr.io
    username: ${{ github.actor }}
    password: ${{ secrets.GITHUB_TOKEN }}

- name: Build and push
  uses: docker/build-push-action@v5
  with:
    push: true
    tags: |
      ghcr.io/${{ github.repository }}:latest
      ghcr.io/${{ github.repository }}:${{ github.sha }}
TIP

GHCR ne nécessite aucun secret supplémentaire : le GITHUB_TOKEN auto-généré suffit.

6. Push vers AWS ECR

output
- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789012:role/github-actions-ecr
    aws-region: eu-west-3

- name: Login to ECR
  id: ecr
  uses: aws-actions/amazon-ecr-login@v2

- name: Build and push
  uses: docker/build-push-action@v5
  with:
    push: true
    tags: |
      ${{ steps.ecr.outputs.registry }}/myapp:latest
      ${{ steps.ecr.outputs.registry }}/myapp:${{ github.sha }}

7. Semantic versioning des images

Convention SemVer : MAJOR.MINOR.PATCH

TagQuand l'utiliser
1.2.3Version exacte immuable (production strict)
1.2Dernière patch de la mineure 1.2
1Dernière mineure de la majeure 1
latestLa dernière en date (à éviter en prod !)
sha-abc1234Tag basé sur le commit Git
main / developDernière de la branche
pr-42Spécifique à une Pull Request
v1.2.3-rc.1Release candidate

Avec docker/metadata-action

output
- name: Generate tags
  id: meta
  uses: docker/metadata-action@v5
  with:
    images: myuser/myapp
    tags: |
      type=ref,event=branch
      type=ref,event=pr
      type=semver,pattern={{version}}
      type=semver,pattern={{major}}.{{minor}}
      type=semver,pattern={{major}}
      type=sha,prefix=sha-,format=short
      type=raw,value=latest,enable={{is_default_branch}}

# Sortie automatique selon le contexte :
# - sur main : latest, sha-abc1234, main
# - sur tag v1.2.3 : 1.2.3, 1.2, 1, sha-abc1234
# - sur PR #42 : pr-42, sha-abc1234

Chapitre 00.1 — Philosophie CI/CD : Pourquoi automatiser ?

NOTEObjectif de cette leçon — Comprendre les problèmes du développement logiciel traditionnel, découvrir pourquoi l'automatisation CI/CD est devenue incontournable, et apprendre les principes fondamentaux qui guident un pipeline moderne.

1. Le monde avant le CI/CD — La «Integration Hell»

Avant l'adoption des pratiques CI/CD, les équipes de développement travaillaient en silos pendant des semaines ou des mois sur des branches séparées. Lorsqu'elles tentaient d'intégrer leur code, le résultat était souvent catastrophique. On appelait ce phénomène l'Integration Hell (enfer de l'intégration).

🔴 Avant le CI/CD

🟢 Avec le CI/CD

WARNINGStatistique choc — Selon le rapport DORA 2023, les équipes «elite» déploient plusieurs fois par jour avec un taux d'échec de déploiement inférieur à 5 %, contre une fois par mois ou moins pour les équipes «low performers».

2. Le coût du bug — La règle du «Shift Left»

Le principe «Shift Left» (décaler à gauche) signifie qu'il faut détecter et corriger les problèmes le plus tôt possible dans le cycle de développement. Plus un bug est détecté tard, plus il coûte cher à corriger.

Le CI/CD permet de faire remonter les problèmes dès le commit, réduisant drastiquement le coût de correction. Les tests automatisés, l'analyse statique du code et les scans de sécurité s'exécutent à chaque push, bien avant que le code n'atteigne la production.

3. Les trois piliers : CI, CD (Livraison) et CD (Déploiement)

🔵 CI — Intégration Continue

Les développeurs intègrent leur code dans une branche commune plusieurs fois par jour. À chaque intégration, un pipeline automatisé se déclenche : compilation, tests unitaires, analyse de code.

Objectif : détecter les conflits et bugs rapidement.

🟡 CD — Livraison Continue

Le code est toujours dans un état deployable. Après la CI, le pipeline prépare automatiquement une release (package, image Docker) prête à être déployée sur n'importe quel environnement.

Objectif : pouvoir déployer à tout moment, avec approbation humaine possible.

🟢 CD — Déploiement Continu

Tout commit qui passe les tests est automatiquement déployé en production, sans intervention humaine. C'est le niveau ultime d'automatisation, utilisé par Netflix, Amazon, Google.

Objectif : éliminer tout délai entre le code et la valeur utilisateur.

PratiqueFréquence de déploiementApprobation humaineNiveau de confiance requis
ManuelTrimestrielle / AnnuelleToujoursFaible (processus)
CI seulementHebdomadaire / MensuelleToujoursMoyen (tests de base)
CI + CD LivraisonQuotidienne / HebdomadaireOptionnelleÉlevé (tests complets)
CI + CD DéploiementPlusieurs fois/jourJamaisTrès élevé (tests + monitoring)

4. Le pipeline CI/CD — Vue d'ensemble

Un pipeline CI/CD est une chaîne d'étapes automatisées qui transforme un commit de code en une application déployée en production.

ÉtapeDescriptionOutils courantsDurée typique
CodeDéveloppeur pousse du code sur GitGit, GitHub, GitLab
BuildCompilation, résolution des dépendancesMaven, npm, Gradle, Docker1–5 min
Test unitaireTests rapides au niveau des fonctionsJUnit, Jest, pytest1–3 min
Analyse qualitéCode coverage, linting, sécuritéSonarQube, ESLint, Snyk2–5 min
PackageCréation d'un artifact déployableDocker, JAR, ZIP, Helm2–10 min
Test intégrationTests sur un environnement completPostman, Cypress, k65–15 min
Deploy StagingDéploiement sur environnement de testKubernetes, ECS, Heroku2–5 min
Deploy ProdDéploiement en productionRolling, Blue/Green, Canary2–10 min
MonitorSurveillance et alertes post-déploiementPrometheus, Grafana, DatadogContinu

5. Les métriques DORA — Mesurer la performance DevOps

Le projet DORA (DevOps Research and Assessment) a identifié quatre métriques clés qui mesurent l'efficacité d'une organisation DevOps. Ces métriques permettent de situer votre équipe et de définir des objectifs d'amélioration.

📈 Deployment Frequency

va-plus-loin

Cet article couvre les extraits les plus utiles — le cours complet CI CD Pipeline (7 chapitres, 20 leçons, exercices corrigés et projet final) t'emmène jusqu'au bout.

./acceder-au-cours-complet cours gratuit : Maîtriser Claude Code

FAQ

Combien de temps pour apprendre CI CD Pipeline ?
Avec une progression structurée (7 chapitres, 20 leçons courtes et pratiques), on atteint un niveau opérationnel en quelques semaines à raison de 30 à 60 minutes par jour. L'important est de pratiquer chaque notion immédiatement.
Faut-il des prérequis ?
Des bases en informatique suffisent. Si tu sais utiliser un terminal et lire du code simple, tu es prêt.
Par où commencer concrètement ?
Reproduis les commandes de cet article, puis suis le cours complet CI CD Pipeline : il enchaîne les 20 leçons dans l'ordre, avec exercices et projet final.

📬 Tu veux recevoir ce type de guide chaque semaine ? Abonne-toi gratuitement — code réel, zéro blabla.