CI et CD : pourquoi les confondre nuit à vos déploiements

Depuis des années, de nombreuses équipes utilisent leur plateforme d'intégration continue (CI) pour tout faire : construire, tester, packager, déployer et même gérer les rollbacks. Au premier abord, cela semble logique — votre code est déjà sur GitHub ou GitLab, vos pipelines vivent à côté de votre code, et les runners sont déjà configurés. Pourquoi ne pas tout centraliser au même endroit ?

Parce que cette commodité initiale se transforme souvent en couplage problématique à mesure que votre projet évolue. Cet article s'appuie sur une analyse publiée sur dev.to pour explorer pourquoi séparer CI et CD est une décision d'architecture qui mérite votre attention.

CI et CD : deux responsabilités fondamentalement différentes

Il est tentant de traiter CI et CD comme les deux faces d'une même pièce, mais leurs responsabilités sont distinctes.

L'intégration continue (CI) est centrée sur la validation du changement :

• Compiler le code
• Exécuter les tests unitaires et fonctionnels
• Produire des artefacts
• Confirmer qu'un commit est sain

La livraison et le déploiement continus (CD) concernent la propagation contrôlée du changement :

• Sélectionner un release candidate
• Décider où et quand il est déployé
• Définir les flux d'approbation
• Promouvoir un artefact d'un environnement à l'autre
• Gérer les rollbacks en cas d'incident

Ces deux disciplines ont des cycles de vie, des acteurs et des contraintes opérationnelles très différents. Les fusionner dans le même outil crée une dépendance dangereuse : si votre plateforme CI est indisponible, vous perdez non seulement la capacité de valider vos commits, mais aussi celle de déployer en production.

GitHub Actions, par exemple, est documenté comme dépendant de la disponibilité de GitHub même pour les runners auto-hébergés — ceux-ci doivent se connecter à GitHub pour recevoir leurs jobs. En cas de panne du service, votre capacité de déploiement est paralysée, indépendamment de votre infrastructure propre.

Les limites concrètes d'un CI utilisé comme plateforme de déploiement

Dans un contexte Symfony/PHP, cette problématique est particulièrement visible. Voici quelques situations réelles qui illustrent les limites de l'approche "tout dans le CI" :

🔒 Auditabilité insuffisante

Les pipelines CI sont conçus pour tracer les builds, pas les déploiements. Savoir qu'un workflow a tourné ne vous dit pas qui a approuvé le déploiement en production, quel artefact précis a été promu, ni quel était l'état du système avant la mise en production. Dans des contextes réglementés ou avec des clients exigeants, cette lacune est problématique.

⚙️ Logique de déploiement dispersée

Avec une approche CI-as-CD, la logique de déploiement se retrouve fragmentée dans des fichiers YAML de workflow, des scripts shell appelés depuis ces workflows, des secrets stockés à plusieurs endroits, et des conditions d'environnement difficiles à maintenir. Au fil du temps, personne ne comprend vraiment comment fonctionne le déploiement de bout en bout.

🔄 Rollback difficile et risqué

Revenir sur un déploiement raté depuis un CI implique souvent de relancer manuellement un ancien workflow, de modifier temporairement des variables, ou de pousser un commit de revert. Ces procédures sont lentes, sources d'erreurs humaines et rarement testées à froid. Un outil de CD dédié permet de déclencher un rollback en quelques secondes avec une traçabilité complète.

📊 Manque de visibilité sur les environnements

Un CI vous donne une vue sur vos pipelines. Il ne vous donne pas une vue claire sur l'état de vos environnements : quelle version tourne en staging ? Quelle version est en production ? Depuis quand ? Qui l'a déployée ? Ces questions sont essentielles pour les équipes de développement et de support, et elles méritent une interface dédiée.

Vers une séparation claire : l'approche recommandée

La solution n'est pas forcément complexe à mettre en œuvre. L'idée centrale est de laisser le CI faire ce qu'il fait bien — valider et produire des artefacts — puis de déléguer à un outil dédié la responsabilité des déploiements.

Ce que le CI doit faire :

• Lancer les tests PHPUnit, PHPStan, Psalm
• Construire l'image Docker ou l'artefact applicatif
• Publier l'artefact dans un registre (Docker Hub, GitHub Packages, etc.)
• Notifier le système de CD qu'un nouvel artefact est disponible

Ce que le CD doit faire :

• Gérer les environnements (dev, staging, production)
• Appliquer les règles de promotion (ex. : staging validé avant production)
• Requérir des approbations humaines si nécessaire
• Exécuter le déploiement de manière idempotente
• Conserver un historique complet et auditable de chaque déploiement
• Permettre un rollback simple et traçable

Dans un stack Symfony, cela peut se traduire par l'utilisation d'outils comme ArgoCD ou Flux pour du Kubernetes, Deployer avec une orchestration externe, ou des solutions SaaS dédiées au CD. L'important est que la frontière entre "artefact validé" et "déploiement déclenché" soit explicite et contrôlée.

Conclusion : la séparation des responsabilités, aussi pour les pipelines

Le principe de séparation des responsabilités (SRP) est au cœur de toute architecture logicielle saine — que ce soit dans votre code Symfony ou dans votre infrastructure. Il s'applique tout autant à vos outils de livraison.

Traiter votre CI comme une plateforme de déploiement, c'est accepter une dette technique opérationnelle qui se manifeste au pire moment : lors d'un incident en production, d'un audit de sécurité, ou d'une montée en charge de votre équipe.

Séparer CI et CD, c'est investir dans la résilience, la clarté et la maîtrise de votre chaîne de livraison. Pour les équipes MulerTech travaillant sur des projets PHP/Symfony à fort enjeu, c'est une évolution naturelle vers une maturité DevOps durable.

💡 Source originale : Stop Using CI as Your Deployment Platform — Tech Face, dev.to