CI/CD Pipeline — Conventions et workflows

Ce guide définit les conventions pour créer des pipelines CI/CD robustes et sécurisés. Utilise iac_guardrails_scan pour valider les fichiers de configuration.

Principes fondamentaux

1. Sécurité d'abord

• •Jamais de secrets hardcodés dans les fichiers de pipeline
• •Utiliser les secrets natifs de la plateforme (GitHub Secrets, GitLab CI/CD Variables)
• •Limiter les permissions au minimum nécessaire
• •Scanner les dépendances et le code dans le pipeline (dependency_guard, secret_scan)

2. Reproductibilité

• •Pinner toutes les versions (actions, images Docker, dépendances)
• •Utiliser des lockfiles (package-lock.json, poetry.lock)
• •Préférer les tags semver aux branches (actions/checkout@v4, pas @main)
• •Utiliser des digests SHA pour les images Docker critiques

3. Performance

• •Activer le cache pour les dépendances (node_modules, pip cache, .m2)
• •Utiliser le parallélisme (matrix builds, jobs concurrents)
• •Séparer les pipelines (lint rapide vs tests complets)
• •Utiliser des images Docker slim/alpine

4. Fiabilité

• •Définir des timeouts sur chaque job
• •Configurer les retries pour les étapes réseau (install, deploy)
• •Utiliser des health checks post-déploiement
• •Implémenter le rollback automatique

Structure recommandée d'un pipeline

┌──────────┐   ┌──────────┐   ┌──────────┐   ┌──────────┐
│  Lint &  │──▶│  Tests   │──▶│ Security │──▶│  Build   │
│  Format  │   │  Unit    │   │  Scan    │   │          │
└──────────┘   └──────────┘   └──────────┘   └──────────┘
                                                   │
                                                   ▼
                              ┌──────────┐   ┌──────────┐
                              │  Deploy  │◀──│  Tests   │
                              │  Prod    │   │  E2E     │
                              └──────────┘   └──────────┘

Étapes standard

1. •Lint & Format — ESLint, Prettier, Black, Ruff (rapide, fail fast)
2. •Tests unitaires — Jest, Pytest, avec couverture minimum
3. •Security scan — secret_scan, dependency_guard, SAST
4. •Build — Compilation, bundling, Docker build
5. •Tests E2E — Playwright, Cypress (sur l'artefact buildé)
6. •Deploy staging — Déploiement automatique sur staging
7. •Deploy production — Manuel ou auto avec approval

Bonnes pratiques par plateforme

Pour les détails par plateforme :

• •GitHub Actions
• •GitLab CI

Validation avec Collègue

Avant de merger un pipeline, valide-le :

# Appeler iac_guardrails_scan avec le fichier de pipeline
iac_guardrails_scan({
  files: [{path: ".github/workflows/ci.yml", content: "..."}],
  policy_profile: "strict"
})

Patterns CI/CD courants

Matrix build (multi-version)

Tester sur plusieurs versions de runtime (Node 18/20/22, Python 3.10/3.11/3.12). Utilise la stratégie matrix de la plateforme.

Cache efficace

• •Clé de cache = hash du lockfile (hashFiles('**/package-lock.json'))
• •Restore keys par ordre de spécificité
• •Ne pas cacher les artefacts de build (seulement les dépendances)

Deploy progressif

• •Canary : déployer sur 5% du trafic, monitorer, puis 100%
• •Blue/Green : basculer le load balancer entre 2 environnements
• •Rolling : remplacer les instances une par une

Monorepo

• •Détecter les changements par dossier (paths: dans GitHub Actions)
• •Ne builder/tester que les packages modifiés
• •Utiliser des outils comme Turborepo, Nx, ou Lerna

Anti-patterns CI/CD