La CI/CD n’est pas une priorité !

Résumé

Dans beaucoup des équipes que j’ai accompagnées dans une transformation DevOps, la première initiative a été de mettre en place la CI/CD. Cela ressemble à une preuve de sérieux et de modernité. Trop souvent, c’était prématuré, mal compris ou incomplet, et cet article est ce que j’aurais voulu que ces équipes lisent d’abord.

Un pipeline mérite ce nom à trois conditions: il démarre seul à chaque changement, un test, une porte de qualité ou une analyse de sécurité en échec l’arrête, et il déploie avec une stratégie adaptée, Blue/Green, canary, rolling update. Une chaîne qui continue malgré des tests rouges ou des vulnérabilités connues n’est pas de la CI/CD, et une chaîne qui peut casser la production sans pouvoir revenir en arrière est incomplète. Maîtriser la CI sans la CD, ou l’inverse, est un travail parfaitement sérieux.

Avant d’automatiser, quatre choses doivent être réglées: l’architecture, la couche de persistance, les contrôles de qualité et de sécurité, et la stratégie de déploiement et de retour arrière. Sinon le pipeline livre simplement les erreurs plus vite que la valeur. La persistance est la partie que tout le monde oublie et celle qui est souvent irréversible: bases de données, bus de messages, configuration, stockage de fichiers, index de recherche, modèles d’accès, chacun avec son risque et sa pratique, des schémas versionnés aux suppressions logiques conservées quelques versions.

Deux leçons du terrain pour finir. Application et infrastructure ne doivent pas partager un pipeline: elles changent pour des raisons et à des rythmes différents, et le travail d’infrastructure reste orchestré plutôt que continu, avec une validation manuelle là où le rayon d’impact est large. Et la stratégie de déploiement peut se choisir par fonctionnalité, en configuration, dans un petit catalogue de stratégies ayant chacune sa facilité de récupération. La CI/CD n’est pas une case à cocher; c’est un cadre d’exécution fiable et traçable, construit progressivement et sur des standards partagés.

Idées clés

• Un pipeline n’est CI/CD que s’il démarre seul à chaque changement, s’arrête au moindre test, contrôle de qualité ou de sécurité en échec, et déploie avec une stratégie qui permet un retour arrière.
• Fixer d’abord l’architecture, la couche de persistance, les contrôles de qualité et la stratégie de déploiement, sinon le pipeline livre des erreurs plus vite que de la valeur.
• La couche de persistance est le risque oublié parce qu’elle est souvent irréversible: versionner les schémas, garder les anciens consommateurs vivants, supprimer logiquement avant de supprimer physiquement.
• Application et infrastructure méritent des pipelines séparés: déclencheurs, contenus et cadences différents, et une validation manuelle là où l’impact est large.
• La stratégie de déploiement se choisit par fonctionnalité dans la configuration, parmi recreate, rolling update, Blue/Green, feature toggle, canary, A/B testing et shadow release.

Pourquoi j’ai écrit cet article