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.
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.
- Introduction au CICD
- Integration Continue
- Qualite du Code
- Optimisation du Pipeline
- Deploiement Continu
Code Coverage et seuils de qualité
Chapitre 02 • Leçon 03 • Durée : 45 min
- 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.
| Type | Mesure | Exemple |
|---|---|---|
| Line Coverage | % de lignes exécutées | 80 % = 80 lignes sur 100 sont touchées |
| Branch Coverage | % de branches conditionnelles testées | if/else, switch — les 2 chemins doivent passer |
| Function Coverage | % de fonctions appelées | Toutes les fonctions exportées sont-elles testées ? |
| Statement Coverage | % d'instructions exécutées | Proche du line coverage |
| Mutation Coverage | % de mutations détectées par les tests | Plus fiable mais coûteux (mutation testing) |
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
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
[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 = true3. Coverage en JavaScript avec Jest
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 ÉCHOUE4. Coverage en Java avec JaCoCo
<!-- 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.html5. Définir des seuils intelligents
| Type de projet | Seuil recommandé |
|---|---|
| Critical (banking, healthcare, aerospace) | 90-95 % |
| SaaS / Web app production | 80-85 % |
| Backend API | 75-85 % |
| Frontend (UI logic) | 60-70 % |
| Prototype / MVP | 40-60 % |
| Script utilitaire | 0-30 % (souvent inutile) |
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
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: true7. Codecov : visualiser et comparer
codecov.yml pour personnaliser
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
- 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'artifact | Exemple | Registry typique |
|---|---|---|
| Image container | devforge-api:1.2.3 (Docker) | Docker Hub, GHCR, ECR, Quay |
| Package Python | my-lib-1.0.0.whl | PyPI, AWS CodeArtifact, GitHub Packages |
| Package npm | my-lib-1.0.0.tgz | npm registry, GitHub Packages |
| JAR Java | my-app-1.0.jar | Maven Central, Nexus, JFrog Artifactory |
| Binaire compilé | my-cli-linux-amd64 | GitHub Releases, S3 |
| Helm chart | my-chart-1.0.0.tgz | ChartMuseum, OCI registries |
| Fichier ZIP générique | build-output.zip | GitHub Actions Artifacts, S3 |
2. Artifacts GitHub Actions (intra-workflow)
Uploader un artifact
- 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: 30Télécharger dans un job suivant
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/*.whlLes artifacts GitHub sont gratuits jusqu'à 500 Mo par repo public, et expirent par défaut après 90 jours.
3. Container registries comparés
| Registry | Coût | Avantages | Inconvénients |
|---|---|---|---|
| Docker Hub | Gratuit (public) / 5 $/user (private) | Le plus populaire, large ecosystem | Rate limits sur les pulls |
| GHCR (GitHub) | Gratuit (public) / inclus GitHub | Intégration GitHub native | Moins connu |
| AWS ECR | 0.10 $/Go/mois | Sécurité IAM, scan auto, intégré ECS/EKS | Région-spécifique |
| GCR / Artifact Registry | 0.10 $/Go/mois | Intégré GCP, multi-format | Lock-in GCP |
| Azure ACR | Basic 5 $/mois | Intégré Azure | Lock-in Azure |
| Quay.io | Gratuit (public) / payant (private) | Détecteur de vulnérabilités fort | Moins 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
- 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=max5. Push vers GHCR (GitHub Container Registry)
- 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 }}GHCR ne nécessite aucun secret supplémentaire : le GITHUB_TOKEN auto-généré suffit.
6. Push vers AWS ECR
- 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
| Tag | Quand l'utiliser |
|---|---|
1.2.3 | Version exacte immuable (production strict) |
1.2 | Dernière patch de la mineure 1.2 |
1 | Dernière mineure de la majeure 1 |
latest | La dernière en date (à éviter en prod !) |
sha-abc1234 | Tag basé sur le commit Git |
main / develop | Dernière de la branche |
pr-42 | Spécifique à une Pull Request |
v1.2.3-rc.1 | Release candidate |
Avec docker/metadata-action
- 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-abc1234Chapitre 00.1 — Philosophie CI/CD : Pourquoi automatiser ?
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
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.
| Pratique | Fréquence de déploiement | Approbation humaine | Niveau de confiance requis |
|---|---|---|---|
| Manuel | Trimestrielle / Annuelle | Toujours | Faible (processus) |
| CI seulement | Hebdomadaire / Mensuelle | Toujours | Moyen (tests de base) |
| CI + CD Livraison | Quotidienne / Hebdomadaire | Optionnelle | Élevé (tests complets) |
| CI + CD Déploiement | Plusieurs fois/jour | Jamais | Trè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.
| Étape | Description | Outils courants | Durée typique |
|---|---|---|---|
| Code | Développeur pousse du code sur Git | Git, GitHub, GitLab | — |
| Build | Compilation, résolution des dépendances | Maven, npm, Gradle, Docker | 1–5 min |
| Test unitaire | Tests rapides au niveau des fonctions | JUnit, Jest, pytest | 1–3 min |
| Analyse qualité | Code coverage, linting, sécurité | SonarQube, ESLint, Snyk | 2–5 min |
| Package | Création d'un artifact déployable | Docker, JAR, ZIP, Helm | 2–10 min |
| Test intégration | Tests sur un environnement complet | Postman, Cypress, k6 | 5–15 min |
| Deploy Staging | Déploiement sur environnement de test | Kubernetes, ECS, Heroku | 2–5 min |
| Deploy Prod | Déploiement en production | Rolling, Blue/Green, Canary | 2–10 min |
| Monitor | Surveillance et alertes post-déploiement | Prometheus, Grafana, Datadog | Continu |
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
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 CodeFAQ
Combien de temps pour apprendre CI CD Pipeline ?
Faut-il des prérequis ?
Par où commencer concrètement ?
📬 Tu veux recevoir ce type de guide chaque semaine ? Abonne-toi gratuitement — code réel, zéro blabla.