Pipeline CI/CD : de la validation à la production
Un pipeline CI/CD sur un canevas interactif : validation, construction, tests, packaging, déploiement en préparation et en production, et les portes qui décident si une version reste.
CI/CD automatise le chemin depuis une validation de code jusqu'à la production : l'intégration continue crée et teste chaque modification, et la livraison continue la conditionne et la déploie via des portes qui décident si la version est suffisamment saine pour rester.
Pipeline CI/CD : de la validation à la production
Le canevas FlowJam interactif de cette explication : chaque couloir, ligne et flèche ci-dessus appartient à un véritable diagramme QueryChart que vous pouvez ouvrir et modifier.
Comment lire ce visuel
- Lisez les cinq colonnes de gauche à droite : Commit, Compilation et tests, Packaging, Déployer, Surveillance.
- Suivez le changement à travers les voies : il quitte le développeur, est traité par le serveur CI, reste dans le registre et s'exécute sur la cible de déploiement.
- Les deux décisions sont des portes : un « Non » sur l’une ou l’autre envoie la modification à un point de terminaison d’échec explicite au lieu de la transmettre.
Construction et tests
« Le développeur valide le code » démarre le flux, et « le serveur CI construit l'application » et « l'exécution des tests unitaires et d'intégration » sont le travail de l'intégration continue : chaque validation est compilée et testée seule. "Tous les contrôles ont été réussis ?" est la porte qui donne son nom à CI : une validation défaillante est rejetée à "Échec de la construction : correction et recommit" avant de pouvoir contaminer le flux d'artefacts.
Conditionnement et déploiement
« Emballez l'artefact et transférez-le dans le registre » produit la version immuable et versionnée : la chose exacte qui s'exécutera. "Déployer en préparation, exécuter des tests de fumée" le prouve dans un environnement comme la production, puis "Déployer en production" l'expédie. Le chemin de registre est le transfert : l'artefact est construit une seule fois et consommé à chaque étape ultérieure, ce qui rend la version déployée identique à celle testée.
La porte de surveillance
« En bonne santé après le déploiement ? est la décision finale : les métriques, les journaux et les alertes après la sortie décident si "La version est en ligne et surveillée" ou "Revenir à la dernière bonne version". La restauration est considérée comme une véritable étape de retour à l’état final sain, car la restauration automatisée est ce qui sécurise un déploiement rapide.
Relations et enseignements clés
- CI est la porte d'entrée avant toute expédition : créez et testez chaque validation, et rejetez les échecs à la source.
- L'artefact du registre est construit une seule fois et exécuté partout : la reproductibilité du déploiement en dépend.
- La mise en scène prouve l'artefact dans un environnement de type production avant que la production ne le voie.
- L'état de santé après le déploiement est la véritable porte d'entrée : la surveillance, et non le script de déploiement, décide si une version reste.
- Un pipeline sans restauration n’est pas sûr à automatiser ; le canevas utilise la restauration comme chemin de première classe.
Quand utiliser ce visuel
- Enseigner à une équipe la différence entre l'intégration continue et la livraison continue avant de créer un pipeline.
- Concevoir un pipeline : les deux portes indiquent où l'automatisation doit s'arrêter et où le jugement (ou le retour en arrière) doit commencer.
- Audit d'un pipeline existant : une barrière de santé manquante est une version exécutée sans décision.
Comment cela fonctionne
Cartographiez les étapes réelles de votre pipeline
Remplacez les étapes génériques par celles que votre CI exécute (peluches, construction de conteneurs, migration, Canary) en gardant une porte avant que quoi que ce soit ne soit expédié.
Nommez vos chèques
Annotez la zone de test avec les suites et analyses de sécurité réelles que vous exécutez, et que signifie « Tous les contrôles ont réussi ? » la porte nécessite au-delà des tests unitaires.
Ajouter la branche du canari
Insérez une étape Canary entre la préparation et la production : acheminez un petit pourcentage du trafic vers la nouvelle version et surveillez la barrière de santé avant le déploiement complet.
Spécifiez la restauration
Sur la zone de restauration, notez ce qu'il fait réellement sur votre système (redéployer l'image précédente, restaurer une sauvegarde de base de données) et qui ou quoi le déclenche.
Questions fréquentes
Quelle est la différence entre CI et CD ?
L'intégration continue (CI) consiste à créer et tester automatiquement chaque commit, de sorte que les problèmes apparaissent au moment de leur introduction plutôt qu'au moment de la publication. La livraison continue (CD) prend la sortie CI et automatise son chemin vers le déploiement (packaging, préparation, publication) avec des portes décidant du moment où elle est sûre. CI est la première porte du pipeline, CD est tout ce qui suit.
Pourquoi les portes sont-elles importantes dans un pipeline CI/CD ?
Parce que l’automatisation supprime les points de contrôle humains qui permettaient de détecter les problèmes. Les portes du pipeline les remplacent par des décisions : la porte de test arrête une version défaillante avant son expédition, et la porte de santé arrête une mauvaise version après son expédition. Le visuel représente les deux comme formes de décision pour cette raison : un pipeline est aussi fiable que ses portes.
Qu’est-ce qu’un rollback et pourquoi le pipeline en a-t-il besoin ?
Une restauration ramène le système à la dernière version connue lorsqu'une version échoue après le déploiement. Les pipelines en ont besoin parce que les contrôles de santé sont imparfaits et que la production peut mal se comporter d’une manière que la mise en scène n’a jamais montrée. Une restauration automatisée est ce qui permet aux équipes de déployer fréquemment : le coût d'une mauvaise version devient un retour en arrière et non un incident.
Quelle est la place du registre des artefacts ?
Le registre est l'endroit où se trouve l'artefact construit du pipeline avec une version. Chaque étape ultérieure (préparation, production, restauration) déploie l'artefact exact du registre, jamais une reconstruction. C'est ce qui rend le code déployé identique au code testé, et c'est aussi ce qui sécurise le rollback : la dernière bonne version est toujours dans le registre.
Modifier ce visuel dans QueryChart (FlowJam)
Ouvrez ce canevas CI/CD exact en tant que votre propre graphique, renommez les étapes de votre pipeline et ajoutez vos vraies portes.