Processus CI/CD complet, étape par étape

CI (intégration continue) = vérifier automatiquement chaque changement de code.
CD = livrer (Continuous Delivery, avec validation manuelle avant la production) ou déployer (Continuous Deployment, tout est automatique jusqu’à la production).

Vue d’ensemble

Commit, puis Build, Tests, Analyse, Package, Déploiement staging, Tests de validation, Déploiement production, Monitoring.

Les étapes

1. Gestion du code source
Le développeur travaille sur une branche (feature/xyz) et ouvre une Pull Request (PR). Le dépôt (GitHub, GitLab, Bitbucket) déclenche le pipeline automatiquement à chaque push ou PR. On protège aussi la branche main : pas de merge sans pipeline vert et sans revue de code.

2. Récupération et préparation (Checkout + setup)
Le runner (machine éphémère) clone le code, installe le bon runtime (Node, Python, Java…) et restaure le cache des dépendances pour accélérer les builds.

3. Installation des dépendances
npm ci, pip install -r requirements.txt, mvn install, etc. On utilise des versions verrouillées (lockfile) pour que le build soit reproductible.

4. Analyse statique (qualité rapide)

• Lint et formatage (ESLint, Prettier, Ruff) : style et erreurs évidentes.
• Vérification de types (TypeScript, mypy).
• Cette étape est rapide et échoue vite, donc elle passe avant les étapes lourdes.

5. Build (compilation)
On compile ou transpile le code, on empaquette le front-end, etc. Si le build casse, le pipeline s’arrête ici.

6. Tests automatisés

• Tests unitaires : rapides, isolés, nombreux.
• Tests d’intégration : base de données, API, services (souvent avec des conteneurs de test).
• On produit un rapport de couverture de code avec un seuil minimal (par exemple 80 %).

7. Sécurité (DevSecOps)

• SAST : analyse du code (SonarQube, CodeQL, Semgrep).
• Scan des dépendances : vulnérabilités connues (Dependabot, Snyk, Trivy).
• Détection de secrets : clés ou mots de passe commités par erreur (Gitleaks).

8. Packaging (artefact)
On produit un artefact versionné et immuable : image Docker, .jar, .zip, paquet npm… Il est taggé (SHA du commit ou version sémantique 1.4.2) et poussé dans un registre (Docker Hub, GHCR, ECR, Artifactory). Principe clé : on construit une seule fois et on déploie le même artefact dans tous les environnements.

9. Scan de l’artefact
On scanne l’image Docker (Trivy, Grype) pour détecter les vulnérabilités de l’OS et des librairies. Ici s’arrête la partie CI.

10. Déploiement en staging (pré-production)
Le pipeline déploie l’artefact dans un environnement proche de la production. On utilise l’Infrastructure as Code (Terraform, Pulumi, Helm, Kubernetes manifests) pour que l’infrastructure soit elle aussi versionnée et reproductible. Les secrets viennent d’un coffre (Vault, GitHub Secrets, AWS Secrets Manager), jamais du code.

11. Tests de validation en staging

• Tests end-to-end (Playwright, Cypress, Selenium).
• Smoke tests : l’application démarre-t-elle, les endpoints principaux répondent-ils ?
• Tests de performance (k6, JMeter) si nécessaire.

12. Approbation (optionnelle)
En Continuous Delivery, un humain valide avant la production (bouton « Approve », avec fenêtre de déploiement). En Continuous Deployment, cette étape n’existe pas.

13. Déploiement en production
On choisit une stratégie pour limiter les risques :

• Rolling update : remplacement progressif des instances.
• Blue/Green : deux environnements, on bascule le trafic d’un coup (et on revient en arrière instantanément).
• Canary : on envoie 5 % du trafic vers la nouvelle version, puis on augmente si tout va bien.
• Feature flags : le code est déployé mais la fonctionnalité est activée séparément.

14. Vérification post-déploiement
Smoke tests en production et vérification des health checks. Si ça échoue, rollback automatique vers la version précédente.

15. Monitoring et feedback

• Métriques (Prometheus, Grafana, Datadog), logs (ELK, Loki), traces (OpenTelemetry).
• Alertes (Slack, PagerDuty) en cas d’erreurs ou de lenteur.
• Les résultats nourrissent le prochain cycle : bugs, améliorations, tickets.

Exemple minimal (GitHub Actions)

name: CI-CD
on:
  push:
    branches: [main]
  pull_request:
jobs:
  ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with: { node-version: 20, cache: npm }
      - run: npm ci
      - run: npm run lint
      - run: npm test -- --coverage
      - run: npm run build
  deploy-staging:
    needs: ci
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - run: echo "Build image, push au registre, déploiement staging"
  deploy-prod:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production   # approbation manuelle configurable ici
    steps:
      - run: echo "Déploiement production + smoke tests"

Bonnes pratiques

• Échouer vite : mets les étapes rapides en premier.
• Pipeline as code : la config est versionnée avec le projet.
• Builds reproductibles et artefacts immuables.
• Petits commits fréquents plutôt que de gros changements rares.
• Rollback simple et testé.
• Paralléliser les jobs indépendants (lint, tests, scans) pour gagner du temps.

Outils courants