Bonnes Pratiques CI/CD : Maturité, Vitesse & Fiabilité des Pipelines
#ci-cd#devops#automation#testing#infrastructure
Le CI/CD est le pouls de la livraison logicielle moderne. Un pipeline mature est rapide, fiable et sûr. Un pipeline immature est le goulot dont toutes les équipes se plaignent. Cet article cartographie le parcours de maturité et les patterns qui l'accélèrent.
Modèle de Maturité des Pipelines
| Niveau | Nom | Temps de build | Fréquence de déploiement | Caractéristiques |
|---|---|---|---|---|
| 0 | Manuel | N/A | Mensuel | Builds manuels, déploiements FTP |
| 1 | CI basique | >30 min | Hebdo | Builds auto sur push, tests unitaires basiques |
| 2 | CI complet | 15-30 min | Plusieurs/semaine | Tests auto (unitaires + intégration), lint, SAST |
| 3 | CI + CD staging | 10-15 min | Quotidien | Auto-deploy staging, promotion manuelle prod |
| 4 | CI/CD complet | 5-10 min | Plusieurs/jour | Auto-deploy prod, canary/blue-green, feature flags |
| 5 | Livraison continue | <5 min | À chaque commit | Trunk-based, livraison progressive, rollback auto |
Techniques d'Optimisation de Build
| Technique | Impact | Effort | Fonctionnement |
|---|---|---|---|
| Cache de dépendances | -40-60% temps build | Faible | Cache node_modules, pip entre runs |
| Cache de layers Docker | -30-50% temps build | Faible | Réutiliser les layers inchangés |
| Exécution parallèle des tests | -50-70% temps tests | Moyen | Répartir la suite sur plusieurs runners |
| Builds incrémentaux | -60-80% temps build | Moyen | Ne rebuilder que les modules changés (Turborepo, Nx) |
| Images Docker légères | -20-40% push/pull | Faible | Multi-stage builds, base distrôless/alpine |
| Déclencheurs par chemin | -10-30% temps pipeline | Faible | Ne lancer que ce qui a changé |
tadata
Extrait de la fiche « AZ-400 Domain 3b: Packages, Testing and Release Strategies » · Demander la fiche complète
Taxonomie des Feature Flags
Taxonomie des feature flags
tadataTaxonomie des feature flags
| Type de flag | Objectif | Durée de vie | Exemple |
|---|---|---|---|
| Flags de release | Découpler le déploiement de la mise en production | Courte (jours à semaines) | new-checkout-flow = OFF jusqu'au jour du lancement |
| Flags d'expérimentation | Tests A/B, mesure d'impact | Moyenne (semaines à mois) | pricing-page-variant = A|B|C (10 %/10 %/80 %) |
| Flags opérationnels | Kill switches à l'exécution, dégradation gracieuse | Longue (permanente) | enable-recommendation-service = ON (OFF en cas de dégradation) |
| Flags de permission | Droits d'accès, accès bêta | Longue (jusqu'à la disponibilité générale) | beta-ai-features = ON pour le tier entreprise |
| Flags de migration | Migration progressive du backend | Moyenne (jusqu'à 100 % migré) | use-new-payment-processor = 25 % du trafic |
Matrice de Stratégie de Rollback
| Scénario | Stratégie | Temps de recovery | Impact données | Automatisation |
|---|---|---|---|---|
| Mauvais deploy (stateless) | Redeployer image précédente | 1-5 min | Aucun | ArgoCD auto-rollback |
| Mauvais deploy (stateful) | Bascule blue-green | Secondes | Aucun si pas de changement schéma | Manuel ou automatisé |
| Mauvaise migration BDD | Migration corrective | 10-60 min | Doit être rétrocompatible | Manuel |
| Feature causant incidents | Feature flag OFF | Secondes | Aucun | Kill switch automatique |
| Dérive infrastructure | Terraform re-apply | 5-15 min | Aucun | Pipeline CI/CD |
Pyramide de Tests pour CI/CD
tadata
- UI / end-to-endfew, slow, brittle: Playwright, Selenium; run after deploy to test env
- Integration / contractservice + real dependencies or containers; API contracts
- Unit testsmany, ms each, run on every PR; VSTest, xUnit, Jest, pytest
Extrait de la fiche « AZ-400 Domain 3b: Packages, Testing and Release Strategies » · Demander la fiche complète