Aller au contenu
TortueTech
RubriquesGlossaire

CI/CD : Continuous Integration / Continuous Delivery (ou Continuous Deployment)

Infrastructure

CI/CD : Continuous Integration / Continuous Delivery (ou Continuous Deployment). « Intégration continue / livraison continue », par analogie avec une chaîne de montage où chaque pièce est contrôlée à chaque poste avant de partir chez le client.

Diagramme de séquence entre cinq acteurs : Développeur, Dépôt Git, Serveur CI, Registre d'artefacts et Production. 1. Le développeur fait un commit et un push vers le dépôt Git. 2. Le dépôt déclenche le pipeline sur le serveur CI. 3. Le serveur CI lance le build puis les tests automatisés. 4. En cas d'échec, il envoie une alerte au développeur et attend une correction. 5. En cas de succès, il envoie un artefact versionné au registre d'artefacts. 6. Après validation manuelle ou automatique, le registre déploie en production.

Intégration continue : Chaque push déclenche automatiquement compilation et tests sur la branche partagée. On découvre la casse en quelques minutes, pas lors de la grande fusion du vendredi soir.

Livraison ou déploiement : La livraison continue produit un artefact prêt à partir en production, et un humain appuie sur le bouton. Le déploiement continu supprime le bouton : si tout est vert, ça part tout seul.

Le pipeline : Les étapes (build, tests, analyse de code, packaging, déploiement) s'enchaînent et sont décrites en code, souvent en YAML, versionné dans le même dépôt que l'application.

Les limites : Un pipeline vert ne garantit que ce que les tests vérifient vraiment. Et un test désactivé « temporairement » finit toujours par fêter son premier anniversaire.

Voir aussi :CIGitOpsPipelineArtefactSAST

Ce qui arrive si on s'en passe

Sans chaîne CI/CD, aucune modification n'est vérifiée automatiquement avant de rejoindre la branche principale : une régression ou un test cassé n'apparaît qu'après coup. Les contrôles qu'on peut ajouter à chaque étape (analyse statique, audit des dépendances, recherche de secrets dans le code) ne tournent que si quelqu'un pense à les lancer, donc de façon irrégulière. Le déploiement se fait à la main : il dépend des gestes de la personne qui l'effectue, il est difficile à reproduire, et des accès de production se retrouvent sur des postes individuels. La traçabilité disparaît aussi : rien ne relie avec certitude la version en service à un commit, à un journal de build et aux tests réussis. Enfin, la reprise est plus lente, car revenir en arrière oblige à reconstruire un artefact au lieu de redéployer celui qui a déjà été validé.

Explication de la marmotte

Imagine une équipe qui écrit ensemble le même logiciel, un peu comme plusieurs cuisiniers sur une seule recette. Chaque fois que quelqu'un modifie une ligne, un robot goûte aussitôt le plat : il vérifie que tout se prépare encore, que rien n'est brûlé, que le goût n'a pas changé par erreur. Si ça rate, il prévient tout de suite celui qui vient de toucher à la recette. Si tout va bien, le plat est prêt à servir : dans certaines cuisines quelqu'un donne le feu vert, dans d'autres il part en salle tout seul. Résultat : moins de mauvaises surprises, des corrections rapides, et des améliorations qui arrivent chez les utilisateurs plusieurs fois par jour au lieu d'une fois par an.

Où ce terme est utilisé

← Tout le glossaire